Git Flow，Git团队协作最佳实践
Git是一个很好的版本管理工具，不过相比于传统的版本管理工具，学习成本比较高，实际开发中，如果团队成员比较多，开发迭代频繁，对Git的应用比较混乱，会产生很多不必要的冲突或者代码丢失等。
就像写代码需要代码规范一样，使用Git进行代码管理同样需要一个清晰的流程和规范， Git Flow就是一个被广泛认可的Git使用最佳实践。
Git Flow是Vincent Driessen提出的一个分支管理的策略，http://nvie.com/posts/a-successful-git-branching-model/，
应用这个规范可以使得版本库的演进保持简洁，主干清晰，各个分支有不同的职责，在很大程度上减少冲突的产生。
Git Flow开发流程
Git Flow通过对分支的管理，实现版本迭代的清晰。
这个流程图是应用Git Flow的标准流程，可以看到，不同的分支在产品研发和上线的不同阶段有不同的作用，扮演了不同的角色。
https://images2015.cnblogs.com/blog/524341/201701/524341-20170112192235150-1905124194.png
Git Flow不同分支的角色
结合图片，简单介绍一下不同分支的职责。
1.Production分支
这个分支是发布到生产环境的代码，这个分支只能从其他分支合并，不能在这个分支直接修改。
2.Develop分支
这个分支是主开发分支，包含所有要发布到下一个Release的代码，这个主要合并自其他分支，比如Feature分支。
3.Feature分支
Feature 分支主要用来开发一个新的功能，一旦开发完成，合并回Develop分支，并且进入下一个Release，Feature分支可以选择删除或者保留。
4.Release分支
当需要发布一个新Release的时候，基于Develop分支创建一个Release分支，Release分支在测试过程中可能会修改，完成Release后，合并到Master和Develop分支。
5.Hotfix分支
当在Production发现新的Bug时候，需要创建一个Hotfix分支, 完成Hotfix后，合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release。
Git Flow使用原则
[*]Master分支是线上稳定分支，Release通常用作测试分支，Develop分支是开发应用的主分支
[*]所有的功能开发都在Feature分支进行，然后合并到Develop分支
[*]Release分支发布后出现问题，直接在Release分支修改，避免Develop分支代码污染
Git Flow分支协作最佳实践
我们在应用Git Flow的时候，也遇到了一些问题，比如开发结束后，在develop分支进行merge开发分支操作，出现冲突如果不能很好的解决，容易对develop分支的代码造成污染。
下面是实际开发中使用的流程，在Feature分支上合并develop代码，然后合并到develop分支上，流程更加清晰，冲突优先在开发分支解决。
一个开发人员典型的提交流程：
//新建分支
git checkout develop
git pull origin develop
git checkout -b myfeature
//在分支上开发
git add ***
git commit -m "*****"
//在分支开发过程中合并develop分支到本分支（先把自己的工作commit到本地）
git checkout develop
git pull origin develop
git checkout myfeature
git merge develop
（如果没有冲突，就继续开发，如果有冲突，执行下面过程）
首先在本地解决冲突，再把冲突解决commit
git add ***
git commit -m "*****"
//在分支开发结束，需要将本分支合并到develop分支（先把自己的工作commit到本地）
git checkout develop
git pull origin develop
git merge myfeature
（如果没有冲突，就推送到远程）
git push origin develop
（如果有冲突，则解决冲突，再commit，并推送到远程：）
git add ***
git commit -m "*****"
git push origin develop
应用Git Flow的目的是更好的进行版本管理和持续集成，有些细节并不一定要遵循这个模型，可以根据团队规模进行简单的调整，适合的才是最好的。
页:
[1]