Git教程 - 11 最佳实践

在实际的项目开发工作中，我们该如何使用 git 进行代码管理呢，有哪些最佳实践呢？

这里介绍一下 Git flow 工作流。

11.1 Git flow工作流

原文：https://nvie.com/posts/a-successful-git-branching-model/

下面介绍一下为什么需要那么多的分支：

• master 分支

如果只有一个 master 分支，此时我们在主分支上开发一个新功能，还没开发完成，突然要发布服务器。

怎么办，一个分支没办法支持，于是引入develop分支。

• master 分支

• develop 分支

有了 develop 分支，我们开发的时候在 develop 分支上开发新功能，开发完成的代码，合并到 master 分支，master 分支始终是一个可以发布的分支。

但是现在在 develop 分支上开发登录功能，还没开发完成，老板说放一放，注册功能优先，先开发注册功能。

怎么办，难道丢弃未开发完成的登录功能吗？

于是引入 feature 分支。

• master 分支
• develop 分支
• feature 分支

master 分支是一个可以发布的稳定版本分支；

develop 分支是一个包含了最新功能的最新版本；

每次要开发一个新功能，就从 develop 分支创建一个feature分支，例如开发登录功能，就创建一个 feature-login 分支。登录功能没开发完成，老板要求优先开发注册功能？没关系，切换到 develop 分支，重新创建一个 feature-register 分支，开发注册功能。

登录功能开发完成，就将 feature-login 分支的代码合并到 develop 分支 上。这个 feature-login 分支就可以删除了。

而 master 分支和 develop 分支是一直存在的。

但是现在线上发布的版本有bug，怎么办？不能直接在 master 分支改，develop分支包含新的功能，也不能在develop 分支改。

所以引入 hotfixes 分支。

• master 分支
• develop 分支
• feature 分支
• hotfixes 分支

这样有了bug，就从 master 分支上创建 hotfixes 分支。

修改完bug，将hotfixes 分支合并到 master 分支 和 develop 分支。

但是又遇到一个新问题：现在要发布新版本，在 develop 分支的某个节点要发布新版本，但是还是有人不停地开发完了新功能合并到 develop 分支怎么办？

所以引入 release 分支。

• master 分支
• develop 分支
• feature 分支
• release分支
• hotfixes 分支

在 develop 分支上创建 release 分支，用于发布新版本，这样有人提交代码到 develop 分支就不会影响我要发布的版本了。

创建 release 预发布分支后，需要对预发布版本进行测试，如果测试出问题，可以直接在 release 分支进行修改，也可以创建分支进行修改。

发布新版本后，将release分支合并到 master 分支和 develop 分支，并给master分支打上tag，然后将 release分支删除。

重新再总结一下各个分支的规范：

1. 主分支管理：

   • master 分支是主分支，应保持稳定、可部署状态。
   • 每次发布新版本后，需要将 release 分支合并到 master 分支上，并打上对应的版本号。
   • 不能在 master 分支上直接提交代码；

2. 开发分支

   • develop 分支是开发分支，应包含最新、最全的功能。
   • 合入 develop 分支必须保证功能完整，不影响开发分支的正常运行。

3. 功能分支

   • feature 分支是功能分支，是用来开发新功能的分支。
   • feature 分支从 develop 分支创建，开发完成，合并回 develop 分支。
   • feature 分支只存在于开发者本地，不能被提交到远程库，除非多人合作开发同一个功能，所以要注意功能粒度的把握。
   • feature 分支的命名应清晰描述功能，例如 feature/login-page

4. 预发布分支

   • release 分支是预发布分支，当计划发布新版本时，从 develop 分支创建 release 分支；
   • 在 release 分支打包给测试人员进行测试；
   • 测试发现问题，开发人员可在该分支修改并提交；
   • 发布后，release 分支需合并回 develop 分支 和 master 分支；
   • release 分支的命名格式为 release/x.x.x；

5. 热修复分支

   • hotfix 分支为热修复分支，当线上版本发现 bug，则从主分支创建 hotfix 分支；
   • hotfix 分支的命名格式为 hotfix/x.x.x/bug#1102，编号为码云上的bug编号；
   • 修改完成，hotfix 分支需合并回 develop 分支 和 master 分支；

11.2 Git flow工作流的优缺点

优点：

• 流程清晰，覆盖面全，通过分支模型将工作流串通
• git flow作为最早提出的分支模型，也是最广泛使用的分支模型，受众广泛。
• 以master作为生产分支，面向单版本的线上产品迭代

缺点：

• 分支十分复杂，敏捷性较差
• 仅master分支上做持续集成，而大部分工具默认将master分支设为默认分支，因此经常面临分支切换，导致很繁琐
• 修补分支和发布分支设置繁琐，比如每次使用修补分支都需要同时合并到master和develop分支，但开发经常犯错误，比如忘记合并回develop分支。