Brach

团队项目的Git分支如何管理?

Brach


Git 是目前最流行的源代码管理工具 。大量的软件项目由 GitHub、Bitbucket 和 GitLab 这样的云服务平台或是私有的 Git 仓库来管理 。在使用 Git 时通常会遇到的一个问题是采用何种分支管理实践 , 即如何管理仓库中作用不同的各类分支 。和软件开发中的其他实践一样 , Git 分支管理并没有普遍适用的最佳做法 , 而只有对每个团队和项目而言最适合的做法 。
简单来说 , 在项目开发中使用多个分支会带来额外的管理和维护开销 , 但是多个分支对于项目的团队合作、新功能开发和发布管理都是有一定好处的 。不同的团队可以根据团队人员组成和意愿、项目的发布周期等因素选择最适合的策略 , 找到最适合团队的管理方式 。这里讲一下三种常见的 Git 分支管理方式 。单主干单主干的分支实践(Trunk-based development , TBD)在 SVN 中比较流行 。
【Brach】Google 和 Facebook 都使用这种方式 。trunk 是 SVN 中主干分支的名称 , 对应到 Git 中则是 master 分支 。TBD 的特点是所有团队成员都在单个主干分支上进行开发 。当需要发布时 , 先考虑使用标签(tag) , 即 tag 某个 commit 来作为发布的版本 。如果仅靠 tag 不能满足要求 , 则从主干分支创建发布分支 。
bug 修复在主干分支中进行 , 再 cherry-pick 到发布分支 。图 1 是 TBD 中分支流程的示意图 。图 1. TBD 中的分支流程的示意图由于所有开发人员都在同一个分支上工作 , 团队需要合理的分工和充分的沟通来保证不同开发人员的代码尽可能少的发生冲突 。持续集成和自动化测试是必要的 , 用来及时发现主干分支中的 bug 。
因为主干分支是所有开发人员公用的 , 一个开发人员引入的 bug 可能对其他很多人造成影响 。不过好处是由于分支所带来的额外开销非常小 。开发人员不需要频繁在不同的分支之间切换 。GitHub flowGitHub flow 是 GitHub 所使用的一种简单的流程 。该流程只使用两类分支 , 并依托于 GitHub 的 pull request 功能 。
在 GitHub flow 中 , master 分支中包含稳定的代码 。该分支已经或即将被部署到生产环境 。master 分支的作用是提供一个稳定可靠的代码基础 。任何开发人员都不允许把未测试或未审查的代码直接提交到 master 分支 。对代码的任何修改 , 包括 bug 修复、hotfix、新功能开发等都在单独的分支中进行 。
不管是一行代码的小改动 , 还是需要几个星期开发的新功能 , 都采用同样的方式来管理 。当需要进行修改时 , 从 master 分支创建一个新的分支 。新分支的名称应该简单清晰地描述该分支的作用 。所有相关的代码修改都在新分支中进行 。开发人员可以自由地提交代码和 push 到远程仓库 。当新分支中的代码全部完成之后 , 通过 GitHub 提交一个新的 pull request 。
团队中的其他人员会对代码进行审查 , 提出相关的修改意见 。由持续集成服务器(如 Jenkins)对新分支进行自动化测试 。当代码通过自动化测试和代码审查之后 , 该分支的代码被合并到 master 分支 。再从 master 分支部署到生产环境 。图 2 是 GitHub flow 分支流程的示意图 。图 2. Github flow 中的分支流程的示意图GitHub flow 的好处在于非常简单实用 。
开发人员需要注意的事项非常少 , 很容易形成习惯 。当需要进行任何修改时 , 总是从 master 分支创建新分支 。完成之后通过 pull request 和相关的代码审查来合并回 master 分支 。GitHub flow 要求项目有完善的自动化测试、持续集成和部署等相关的基础设施 。每个新分支都需要测试和部署 , 如果这些不能自动化进行 , 会增加开发人员的工作量 , 导致无法有效地实施该流程 。

推荐阅读