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

时间:2023-03-08 16:50:22

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

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

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