Git 工作流你可以理解为工作中团队成员遵守的一种代码管理方案,在 Git 中有以下几种工作流方案作为方案指导:
下面针对性说下每个工作流可能使用到的场景和适用性:
集中式工作流
集中式工作流 | center
这种工作方式跟 svn 类似,它只有一个 master 分支,开发者会先把远程的仓库克隆到本地,之后的修改和提交都在本地操作,直到在某个合适的时间点将本地的代码合入到远程 master。这种工作流比较适合小团队,因为小团队可能不会太多的协作和合流的动作。
功能开发工作流
这种工作流关注功能开发,不直接往 master 提交代码保证它是稳定并且干净的,而是从 master 拉取 feature 分支进行功能开发,团队成员根据分工拉取不同的功能分支来进行不同的功能开发,这样就可以完全隔离开每个人的工作。当功能开发完成后,会向 master 分支发起 Pull Request,只有审核通过的代码才真正允许合入 master,这样就加强了团队成员之间的代码交流,也就是我们常说的 Code Review。
Gitflow 工作流
这个工作流其实也是我们团队采用的工作流,这也是很多团队会采用的工作流,它会相对复杂一点,但它非常适合用来管理大型项目的发布和维护,后面笔者也会详细讲下这一块。贯穿整个开发周期,master 和 develop 分支是一直存在的,master 分支可以被视为稳定的分支,而 develop 分支是相对稳定的分支,特性开发会在 feature 分支上进行,发布会在 release 分支上进行,而 bug 修复则会在 hotfix 分支上进行。笔者也是花了不少时间才熟练掌握整个工作流,期间遇到不少坑,后面会跟大家分享下。
Forking 工作流
Forking 工作流对于开源项目贡献者一定不陌生了,它有一个公开的中央仓库,其他贡献者可以 Fork(克隆)这个仓库作为你自己的私有仓库,开源项目维护者可以直接往中央仓库 push 代码,而代码贡献者只能将代码 push 到自己的私有仓库,只有项目维护者接受代码贡献者往中央仓库发起的 pull request 才会真正合入。
小结一下
上面已经大致讲了在 git 当中的四种比较常见的工作流,都是需要开发者去实践理解的。
关于 git 工作流,只有选用最合适自己团队的工作流才能有效的提高开发效率,上面提到的一些工作流模式都有各自的适用场景,如何选用适合自己团队的工作流得结合团队成员的实际情况,看团队成员对于工作流的理解程度,还有对于工作流的执行程度。
现在讲下我们团队针对 Gitflow 的一些实践:
master 分支
develop 分支
feature 分支
release 分支
hotfix 分支
大家可能会发现我们这个跟标准的 Gitflow 工作流有些差别,其实也没有什么标准不标准的,前面说到要结合团队的实际情况,我们团队对于目前所采用的工作方式都是达成共识的,所以有一些差异并没有关系。
说了这么久,还没有一句 git 命令,那就让大家感受一下吧(感谢 Bugly 小色熊整理):
1). 首先将远程代码拉取到本地
- git clone xxx
- git checkout -b develop origin/develop
2). 新建 feature 分支
- git checkout -b feature
3). 多人在 feature 上开发,如果中途需要将 develop 的变更合入 feature,所有人需要将本地的代码变更提交到远程
- git fetch origin
- git rebase origin/feature
- git push origin feature
然后由 feature 负责人 rebase develop 分支,删除原来 feature 分支,重新新建 feature 分支;
- git fetch origin
- git rebase origin/feature
- git rebase develop
- git push origin :feature
- git push origin feature
这样可以保证 feature 保持线性变更;
4).feature 开发完成后,所有人需要将本地的代码变更提交到远程
- git fetch origin
- git rebase origin/feature
- git push origin feature
然后由 feature 负责人 rebase develop 分支,然后将 feature 分支合入 develop,删除 feature;
- git fetch origin
- git rebase origin/feature
- git rebase develop
- git checkout develop
- git merge feature
- git push origin :feature
这样可以保证 develop 保持线性变更,各 feature 的变更完整可追溯;
5). 合入 feature 后拉出对应的 release/feature 分支,后续 bug 修复在 release/feature 上
- git checkout develop
- git checkout -b release/feature
release/feature 分支的同步合并与 feature 分支相同
6).release/feature 分支 bug 修复完成后,拉取对应的 tag 推送远程进行发布
- git tag -a v1.0 -m 'feature发布'
- git push origin v1.0
之后将 release/feature 合入 develop 分支,然后删除
- git rebase develop
- git checkout develop
- git merge release/feature
- git push origin :release/feature
7). 发布完成后将 release 合入 master 分支,保证 master 为最新稳定版本(实际操作为发起 merge request)
本篇文章主要针对笔者工作中对于 git 工作流的一些理解和实践,目前我们团队也是严格按照这样的工作流来完成日常的开发工作,一个让团队成员认可并且有效的工作流才是最适合我们的工作流,任何规则不是为了限制我们思考,而是为了让工作更加高效有序,尽量减少人为的失误。git 是一个博大精深的东西,笔者也是不断在实际应用中去理解它,任何一门技术的学习也是这样,就像程序员常用来装逼的一首诗:
参考资料:
来源: http://www.bubuko.com/infodetail-1949971.html