关于后端:Git进阶系列-2-Git中的分支策略

Git 是最风行的代码版本控制系统，这一系列文章介绍了一些 Git 的高阶应用形式，从而帮忙咱们能够更好的利用 Git 的能力。本系列一共 8 篇文章，这是第 2 篇。原文：Branching Strategies in Git^[1]

简直所有的版本控制系统 (VCS) 都有某种类型的分支反对。简而言之，分支意味着能够创立一个新的、独立的容器而来到主开发线，并持续在那里工作。通过这种形式，能够在不毁坏生产代码库的状况下进行试验和尝试。Git 用户晓得 Git 的分支模型十分非凡，而且十分弱小，这是 Git 最酷的性能之一。Git 的分支模型疾速且轻量，在分支之间来回切换的速度与创立或删除分支一样快。能够说 Git 激励应用大量分支和合并的工作流。

Git 把创立多少分支以及合并的频率齐全交给了开发者决定。如果你单独编写代码，能够自由选择什么时候创立新分支，以及保留多少个分支。但当咱们在团队中工作时，状况就不同了。Git 提供工具，然而团队须要负责以最佳形式应用这一工具！

本文将探讨分支策略和不同类型的 Git 分支，还会介绍两种常见的分支工作流: Git Flow 和 GitHub Flow。

Git 进阶系列:

1. 创立完满的提交
2. Git 中的分支策略（本文）
3. 基于 Pull Request 实现更好的合作
4. 合并抵触
5. Rebase vs Merge
6. 交互式 Rebase
7. Git 中的 Cherry-pick 提交
8. 用 Reflog 复原失落的提交

团队单干: 制订规定

在摸索构建公布和集成变更的不同办法之前，先来讨论一下规定。如果在团队中工作，须要对我的项目的通用工作流和分支策略达成统一，最好将其写下来，让所有团队成员都能看到。

诚然，并不是每个人都喜爱编写文档或指导方针，但将最佳实际记录在案不仅能够防止谬误和抵触，还有助于培训新团队成员。解释分支策略的文档将帮忙他们了解团队是如何工作的，以及如何处理软件版本。

以下是咱们本人文档中的一些例子:

• master代表以后的公开公布分支
• next示意下一个公开公布分支(这样咱们就能够在 master 上提交修补程序而不会引入不必要的更改)
• 个性分支被分组在 feature/ 下
• WIP 分支被分组在 wip/ 下(能够用来创立集体 WIP 的“备份”)

不同团队可能对这些规定有不同认识(例如“wip”或“feature”组)，这必定会反映在他们本人的文档中。

集成变更和结构化公布

当咱们思考如何在 Git 仓库中应用分支时，应该从思考如何集成变更和如何构建公布开始。所有这些话题都是严密相连的，为了更好的了解不同的抉择，咱们来看下两种不同的策略。上面的例子是为了阐明极其状况会怎么样，从而帮忙你思考如何设计本人的分支工作流:

• 主线开发
• 状态分支、公布分支和个性分支

第一个抉择能够被形容为“始终集成”，基本上能够归结为: 始终将本人的工作与团队的工作集成在一起。在第二种策略中，收集本人的工作并公布，即多个不同类型的分支进入预发阶段。两种办法各有利弊，两种策略都实用于某些团队，但不适用于另一些团队，大多数开发团队在这两个极其之间工作。

咱们从主线开发开始解释这个策略是如何工作的。

主线开发

之前提到过，这种办法的座右铭是“总是集成”。只有一个独自的分支，每个人都在主线上开发:

记住，这是一个简化的例子，我狐疑在事实世界中是否有任何团队可能应用如此简略的分支构造。然而，了解这个模型的长处和毛病的确有帮忙。

首先，只有一个分支，因而很容易跟踪我的项目中的变动。其次，提交必须绝对较小: 在一直集成到生产代码的环境中，不能冒险进行大而臃肿的提交。因而，团队的测试和 QA 规范必须是一流的！如果没有一个高质量的测试环境，主线开发方法就不适宜。

状态分支、公布分支和个性分支

上面看看另一种状况，如何应用多个不同类型的分支。每个分支都有不同的工作: 新个性和试验代码保留在本人的分支中，公布能够在本人的分支中布局和治理，甚至开发流程中的各种状态也能够用分支来示意:

记住，这齐全取决于团队和我的项目的需要。尽管这种办法一开始可能看起来很简单，但齐全是一个练习和习惯的问题。

当初，让咱们更具体地探讨两种次要的分支类型: 长期分支 (long-running branches) 和短期分支(short-lived branches)。

长期分支

每个 Git 仓库至多蕴含一个长期分支，通常称为 master 或main。当然，团队可能会决定在我的项目中应用其余长期分支，例如相似于 开发 (develop)、生产(production) 或预发 (staging) 分支。所有这些分支都有一个共同点: 存在于整个我的项目生命周期中。

像 master 或main这样的主线分支是长期分支的一个例子。此外，还有所谓的集成分支，如开发或预发。这些分支通常代表我的项目公布或部署过程中的状态。如果代码在开发生命周期中经验了不同的状态（例如，从开发阶段到预发阶段再到生产阶段），在分支中的这个镜像构造也是有意义的。

对于长期分支的最初一点: 大多数团队都有一个相似于“不要间接向长期分支提交内容”的规定，通常通过 merge 或 rebase 来集成。制订这项规定有两个次要起因:

• 品质: 不应将未经测试或评审的代码公布到生产环境中。
• 捆绑公布和调度: 可能心愿分批公布新代码，甚至提前安顿公布。

接下来是短期分支，通常为特定目标而创立，而后在代码集成后删除。

短期分支

与长期分支相同，短期分支是为长期目标而创立的，一旦它们实现了职责并且代码被集成到主线 (或另一个长期分支) 中，就会被删除。有许多不同的起因须要创立短期分支，例如致力于新的实验性个性，修复 bug，重构代码，等等。

短期分支通常基于长期分支创立。假如咱们开始有一个新个性的开发，能够基于长期的主分支创立新个性分支。在若干次提交和测试之后，工作实现，新个性能够集成到主分支中，并且 merge 或 rebase 之后，能够删除个性分支。

两种风行的分支策略

最初咱们看一下两种风行的分支策略: Git Flow 和 GitHub Flow。尽管不同的团队可能会决定齐全不同的分支策略，但这两种风行的策略能够作为团队分支策略的灵感起源。

Git Flow

Git Flow^[2]是一个驰名的分支策略，其中 main 分支总是反映以后的生产状态，此外还有第二个长期分支，通常称为 develop。所有个性分支都从这里创立，并将合并到develop 中。而且，该分支是新公布的终点: 开发人员创立一个新的 release 分支，在下面工作、测试、提交 bug 修复。一旦一切正常，并且确信曾经筹备好投入生产，就将它合并回 main。作为最初一步，在main 上为公布增加一个标签，并删除 release 分支。

Git Flow 对于可打包的软件 (桌面) 应用程序或库来说工作得很好，但对于网站我的项目来说仿佛有点过头了。在这类我的项目里，main分支和 release 分支之间通常区别不大，分不同的分支没有特地大的益处。

如果应用的是像 Tower 这样的 Git 桌面 GUI，能够在界面中找到可能的操作，不须要记住任何新命令:

GitHub Flow

如果团队遵循短生产周期和频繁公布的继续交付形式，倡议看看 GitHub Flow^[3]。

这种形式十分精益和简略: 有一个长期分支，即默认的 main 分支，任何正在做的工作都有本人独立的分支，无所谓是新个性、bug 修复还是重构。

“最好”的 Git 分支策略是什么?

如果问 10 个不同的团队他们是如何应用 Git 分支的，可能会失去 10 个不同的答案。没有所谓的“最佳”分支策略，也没有每个人都应该采纳的完满工作流。为了找到最适宜团队的模型，应该坐下来剖析所做的我的项目，探讨公布策略，而后决定一个分支工作流，从而以最好的形式反对咱们的我的项目。

如果想更深刻理解高级 Git 工具，能够收费查看“Advanced Git Kit^[3]”: 这是对于分支策略、交互式 Rebase、Reflog、子模块等主题的短视频汇合。

References: \
[1] Branching Strategies in Git: https://css-tricks.com/branching-strategies-in-git/ \
[2] A Successful Git Branching Model: http://nvie.com/posts/a-successful-git-branching-model/ \
[3] GitHub Flow: https://guides.github.com/introduction/flow/

你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。\
微信公众号：DeepNoMind

本文由 mdnice 多平台公布