Git分支和迭代流程_gitee迭代怎么使用

Git分支

feature分支：功能分支

dev分支：开发分支

test分支：测试分支

master分支：生产环境分支

hotfix分支：bug修复分支。从master拉取，修复并测试完成merge回master和dev。

某些团队可能还会有 realese分支：预发布分支。

release 为预上线分支，提测阶段，会以release分支代码为基准提测，用于QA测试。release分支内容可以从feature分支合并，测试完成merge回master。

一、Git版本迭代

1.版本开始：从远程master分支拉出新的远程feature分支

2.本地开发：本地checkout到feature分支

3.提交代码：本地feature推送到远程feature分支

4.开发自测：feature分支，合并到远程dev分支。

5.测试环节：开发自测完毕后，开发提测，进入测试环节。把远程feature分支，合并到远程test分支。。

6.测试完毕，远程feature分支，合并到master。发版。

feature分支，合并到远程dev分支

• 本地先切到dev分支。
  

• 然后将远程的feature分支合并到本地dev分支
  

• 再将本地dev分支推送到远程的dev分支。

• 切回本地的feature分支。

处理合并冲突

如果A同学在featureA分支，B同学在featureB分支，分别修改相同的内容，那么在合并到dev分支时，就会有冲突。这时需要处理合并冲突：

• 如果发现代码有冲突，可以尝试将master的代码合并到自己的feature，再合并到dev分支。

因为feature分支是从master分支拉出来的，如果还有新的feature分支提交到master，那么自己的feature分支代码就是滞后的。

• 如果还是有冲突，自己修改的就自己合并，如果不是自己写的代码，那可以找修改代码的同学进行合并。
  

可以选择左边的远程分支上的代码，也可以选择右边的代码，而中间是合并的结果。

cherry pick 摘取其他分支的comment

如果想把 feature_v1.0 分支的comment 摘到 feature_v1.0_new 分支上，
需要先切换到 feature_v1.0_new分支，然后点击 下面菜单栏的 git，点击Local Changes旁边的 Log，这时能看到 local和remote的分支，点击feature_v1.0分支。
从feature_v1.0，选中自己需要的comment，点击cherry pick，就能摘到 feature_v1.0_new。

check pick结果如下：

三、注意点：

• 代码已经提交到master分支并发布，那么就不要再修改对应的feature分支。保留现场。

• dev分支、test分支的代码，不要合并到feature分支。

因为dev分支、test分支可能是包含多个feature的，一旦feature分支被污染，包含了其他feature的内容，

那么feature分支合并到master的代码，就可能包含未测试的代码。这会导致生产问题。

dev分支不小心合并到feature分支，怎么处理？

• Idea(或者其他开发工具)新建一个文件夹，从Git重新clone，不然可能会读到本地缓存。(开发工具没有本地缓存就不需要做这一步)

• 从master重新拉feature-new分支在本地切换到这个新的feature-new分支。
  

• 从Git提交记录中，选择旧的远程feature分支，选中自己需要的内容，做cherry-pick,提交人选择自己，被污染的部分不要cherry-pick。
  从最旧的记录一直cherry-pick,直到最新的记录。

• 备份旧的feature分支 feature-backup,并删除掉旧的feature分支。
  从feature-new分支，拉取出新的feature分支。分支没有污染了。

release分支有什么用？

如果发版时，要发布的服务和功能非常多，如果直接合并到 master 分支，验证不通过的话，回滚会非常麻烦。因此，先从 feature 分支合并到 release 分支，在验证通过后，才将 release 分支合并到 master 分支，会更加稳妥一些。

参考资料

https://www.cnblogs.com/peace-ful/p/15407168.html
注：本文介绍的只是git流程的一种，能够适应多版本并行。也可以使用标准的 git flow流程，详情见：
https://blog.csdn.net/sunyctf/article/details/130587970