Git分支和迭代流程
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