推荐一个git合并步骤,开发分支可能会多次提交合并到dev/master主干分支也会显示很多个提交点,这样不方便代码分支管理和回溯发布记录,所以推荐如下方法,不出意外,这也是个新手教程
本地开发分支建立格式建议 feature_功能_开始时间(示例 feature_test_20230801 ),不推荐使用单一 feature,容易造成冲突和上线功能点不明确,作用好处区分功能点和明确创建时间,后续方便远程分支的删减,精简仓库
本地开发完成后,准备上线测试环境,开发分支合并到dev 分支,测试环境已经设置了选择 dev 分支打包构建,就可以开始测试环境测试阶段了 多功能开发并行时,合并测试环境之前都需要先拉取远程 dev 分支的代码,如果改到相同文件,由后提交人解决冲突,并确定是否存在功能点冲突,最终解决冲突后发布到测试环境(禁止手动修改测试环境和生产环境的文件,紧急情况除外)
发布生成分支时,将测试完成的代码合并到 master 分支,最终构建发布完成测试即可,保证 master 的纯净,合并到 master 分支的代码一定是经常测试环境测试并确定可以上线的代码
# 从master创建开发分支
git checkout -b feature_test_20230801
# 添加代码到开发分支(指定提交文件)
git add .
# 提交
git commit -m '状态识别优化'
# 推到远程开发分支
git push origin feature_test_20230801
# 合并开发分支到测试分支(推荐命令 这样会把feature多个提交点合并为一个提交点,保证分支的清爽简洁)
git checkout dev
git merge --squash feature_test_20230801
git commit -m '格式化代码'
git push origin dev
# 合并开发分支到生产分支
git checkout master
git merge --squash feature_test_20230801
git merge --squash feature_test_20230801
git commit -m '格式化代码'git merge --squash 是一个 Git 命令，它的作用是将当前分支（通常是主分支）与另一个分支（通常是特性分支或分支的分支）进行合并，但不会在历史记录中保留合并的信息。而是将合并的结果作为一次新的提交记录在 Git 历史中。
在你的例子中，feature_test_20230801是一个特性分支的名称，它可能包含了某些特定的功能或修改。使用 git merge --squash 命令可以将该特性分支的修改内容合并到当前分支中，但不会保留合并的历史记录。这意味着在 Git 历史记录中，将不会显示该特性分支与主分支的合并过程，只会显示最终的合并结果。
这样的操作在一些情况下可能会很实用，例如当你希望将一些零散的修改合并到主分支中，但又不希望在 Git 历史记录中显示大量的无关的合并信息时。使用 git merge --squash 可以简化历史记录，使提交记录更加清晰易读。但需要注意的是，这样做会丢失一些合并信息，因此在某些情况下，可能需要考虑其他的解决方案。