Git Flow，Git团队协作最佳实践

dinggela

　　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的标准流程，可以看到，不同的分支在产品研发和上线的不同阶段有不同的作用，扮演了不同的角色。

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的目的是更好的进行版本管理和持续集成，有些细节并不一定要遵循这个模型，可以根据团队规模进行简单的调整，适合的才是最好的。