June's Blog

简介: 为统一团队 git 分支管理规范，刚开始准备自己写，在网上搜了下，发现不少不错的 git 分支管理实践

参考团队的目前使用方式，更贴近于 git-flow，目前欠缺的是 从 dev 到 master 之间用于发布前准备的 release 分支

最后我为团队选择了这个 git 分支管理实践 A successful Git branching model)，网上有不少参考这篇文章写的中文版 gitflow 实践，推荐一个中文版的 Git 最佳实践：有效的 Git 分支模式)

常用的 git flow 的几种有 git-flow, github-flow, gitlab-flow

转载一篇文章: 一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流

此外，可以借助工具gitflow 方便规范使用 git-flow 分支管理模式

GitHub Flow#

特点：#

 以部署为中心的开发模式, 通过简单的功能和规则，持续且高速 安全地进行部署

• master 分支时常保持可以部署的状态
• 进行新的作业时要从 master 分支创建新的分支，新分支名称要具有描述性
• 与 master 分支合并后，立刻部署

前提条件#

• 部署作业完全自动化。必须自动化，一天之类需要多次部署
• 重视测试
  • 让测试自动化
  • 编写测试代码，通过全部测试
  • 维护测试代码

Git Flow#

荷兰程序员 Vincent Driessen 曾发表了一篇博客，让一个分支策略广为人知。具体流程见下图（引用该博客的一幅图片）

高清无码 pdf： https://nvie.com/files/Git-branching-model.pdf

在 Git Flow 中，这 master 和 develop 两个分支至关重要，它们会贯彻整个流程始终，绝对不会被删除，同时绝不允许开发者直接进行修改和提交

要以 develop 分支为起点新建 feature 分支，在 feature 分支中进行新功能的开发或者代码的修正。也就是说 develop 分支维系着开发过程中的最新代码，以便程序员创建 feature 分支进行自己的工作

规范#

主分支 master#

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布

开发分支 develops#

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做 Develop

临时性分支#

使用完以后，应该删除，使得代码库的常设分支始终只有 Master 和 Develop。

• 功能（feature）分支

• 从某种特定功能，从 Develop 分支上面分出来的。开发完成后，要再并入 Develop

• 预发布（release）分支

• 它是指发布正式版本之前（即合并到 Master 分支之前），我们可能需要有一个预发布的版本进行测试

  预发布分支是从 Develop 分支上面分出来的，预发布结束以后，必须合并进 Develop 和 Master 分支。它的命名，可以采用 release-* 的形式

• 修补 bug（fixbug）分支

• 修补 bug 分支是从 Master 分支上面分出来的。修补结束以后，再合并进 Master 和 Develop 分支。它的命名，可以采用 fixbug-* 的形式

Git-flow 简单示例#

详细使用方法可以参考： https://jeffkreeftmeijer.com/git-flow/

mac 使用 homebrew 安装 git-flow :

brew install git-flow

初始化项目：git flow init#

在 feature 分支中工作开发流程：git flow feature start xxxx#

• 从 develop 分支创建 feature 分支
• 从 feature 分支中实现目标功能
• 通过 Github 向 develop 发送 pull request
• 接受其他开发者审核后，将 Pull Request合并至 develop 分支

feature 功能开发完成后: git flow feature finish xxxx

Develop 分支受保护，建议先 push feature 分支到 remote，再提交 pr 合并至 dev 分支

保留原分支命令： git flow feature finish -k my-feature

Reference： https://github.com/nvie/gitflow/wiki/Command-Line-Arguments

在 gitlab 或者 paas 上提交 pr

!!!! Import : 更新本地的 develop 分支

我们发送的 pull request 在 github 端与 develop 合并后，为了让其反应到本地的 develop 分支中，我们需要进行以下操作：

• 切换到 develop 分支
• 执行 git pull (fetch & merge)

每当需要从 develop 分支创建 feature 等分支时，记得一定要先执行上述操作，保证 develop 分支处于最新状态

发版准备#

创建 release 分支 ，在这个分支，我们只处理与发布前准备相关的提交，比如版本编号变更的元数据的添加工作。如果软件部署到预演环境后测试出 bug，相关修正也要提交到这个分支。

注意：该分支绝对不能包含需求变更或者功能变更等重大修正。这一阶段的提交数应该限制到最低

当所有修正处理完后，我们结束这分支

常见问题及解决思路#

特性分支合并冲突#

问题：在完成特性分支并尝试合并到 develop 分支时，可能会遇到合并冲突。

解决办法：

• 在合并前确保 develop 分支的最新更改已经拉取到本地。
• 使用 git merge --no-ff <feature-branch> 来执行合并，这样可以在历史记录中保留合并操作。
• 手动解决冲突，使用 git add <conflicted-file> 添加解决冲突的文件，然后 git commit 提交合并。

特性分支太多，难以管理#

问题：随着时间的推移，项目中可能积累了大量的特性分支。

解决办法：

• 定期清理不再需要的特性分支。
• 使用 git branch -d <feature-branch> 删除本地分支，使用 git push --delete origin <feature-branch> 删除远程分支。
• 对团队成员进行培训，强调完成或废弃特性分支的重要性。

发布分支合并问题#

问题：在准备发布时，从 develop 分支创建的 release 分支可能会在合并到 master 和 develop 时出现问题。

解决办法：

• 在创建发布分支之前，确保 develop 分支是稳定的。
• 在合并到 master 之前，确保所有的测试都通过。
• 使用 git flow release finish 命令时，仔细检查自动生成的合并请求。

紧急修复分支管理#

问题：紧急修复需要快速合并到 master 和 develop 分支。

解决办法：

• 使用 git flow hotfix start <hotfix> 快速创建热修复分支。
• 完成修复后，使用 git flow hotfix finish <hotfix> 命令，确保合并到 master 和 develop。
• 确保在合并后更新版本号和相关文档。

多个团队协作冲突#

问题：在大型项目中，多个团队可能在同一时间工作在不同的特性分支上。

解决办法：

• 使用合并请求（Pull Requests）来进行代码审查和合并。
• 定期召开团队会议，讨论进度和潜在的合并冲突。
• 使用标签和里程碑来跟踪各个团队的工作进度。