如何使用 git - git 工作流程概述

如果您来这里是为了寻求有关使用什么工作流程的建议，我强烈支持微软向其客户提供的建议。

Git 工作流程因开发团队和 Git 服务器（Github、Gitlab 等）而异。Git 技术非常可靠且灵活，人们已经找到了多种可行的工作流程。以下是详细的概述。假设您了解 Git 和功能分支。

我计划根据大家的反馈更新这篇文章。所以，如果您觉得有什么错误或缺失，或者链接过期了，请留言或联系我！

关于同一主题的另一个指南：https://www.codingblocks.net/podcast/comparing-git-workflows/

分叉与集中式工作流程

集中式工作流程 - 即团队中的所有开发人员都具有对共享存储库的读写权限。

这在专业团队中尤为常见。团队成员从中央仓库获取代码，在主题分支上工作，并将他们的分支推送到中央仓库。代码由其他开发者在 Pull 请求中审核。已接受的 PR 将分支合并到master。

分叉工作流程 - 即只有核心开发人员可以更改 repo。

这是开源项目最常见的协作形式。此工作流程的目标是确保公开可见的仓库保持高质量。只有值得信赖的人（例如项目的维护者）才能修改它。非维护者为此类项目做出贡献的方式是通过称为“forking”的过程。它会将整个 git 仓库克隆到您的个人用户帐户中。

假设我想为某个开源项目（比如编程语言 Scala）做贡献，我会前往官方仓库 github.com/scala/scala，然后点击Fork按钮。这会在 github.com/pofl/scala 下创建一个该仓库的副本。这样我就能完全控制这个副本，可以随心所欲地推送代码。

当我想向官方仓库提交贡献时，我会先将我的更改推送到我的 fork 分支。然后，我可以在上游项目中创建一个 Pull 请求。这样的 PR 本质上是请求将我仓库中的一个分支合并到上游仓库。它被称为 Pull 请求，而不是 Merge 请求（顺便说一下，在 GitLab 中是这么叫的），因为“pull”这个词在 GitLab 中是正确的，它指的是从远程仓库获取分支并将其合并到 HEAD 中。

日常工作流程如下：

• 分叉 repo。
• 将您的 fork 克隆到您的计算机（origin）。
• 将官方 repo 添加为远程 ( upstream)。
• 拿来upstream。
• 从 创建一个新分支upstream/master。
• 完成后，将其推送至origin/topic-branch。
• 然后，您可以在上游项目中创建一个 PR，您可以在其中请求合并您的主题分支，就好像它是上游 repo 中的分支一样。
• 解决维护人员提出的所有要求的变更。
• 维护人员接受 PR 并将分支从您的 fork 拉入upstream。

GitHub 的 fork 指南

Git 历史记录卫生

开发人员力求代码整洁。简洁一致的代码更容易、更快速地投入使用。为了实现这一点，团队需要编写代码风格指南并严格执行。Git 作为开发工具的加入，为代码整洁带来了全新的维度。本节将对此进行讲解。

如果您关注互联网上的开发者社区，您会看到一些讨论 Git 历史记录的文章和博客文章。许多人对于什么是干净的历史记录有着不同的看法。奇怪的是，当人们提到 Git 历史记录时，他们实际上指的是提交图的形状master以及其他永久分支。我们将在本节中讨论这一点。我们还将讨论在什么条件下提交是“干净的”。

Git 历史记录的线性

将一个分支合并到另一个分支时，通常会创建一个合并提交，但并非总是如此。Git 默认在没有必要的情况下不会创建合并提交（这称为快进合并）。每当代码贡献被接受时，就会发生合并master，而这正是一些人变得虔诚的契机。幸运的是，大多数人只是接受并习惯了默认行为。

线性历史

有一派人秉持着一种哲学观点，认为提交图应该是线性的。他们希望能够查看 Git 历史记录，并立即了解发生了什么以及谁在做什么。如果历史记录是线性的，那么你看到的只是无噪声分支master和正在进行的功能分支。实现线性历史记录的方法是，在合并/拉取之前将功能分支 rebase 到 master 分支，并强制执行快速合并，从而消除合并提交。

这种方法的缺点是，rebase 的开销相当大，因为它比 merge 涉及更多步骤。当许多人在同一个仓库上工作时，这种方法也会变得很受限，因为有时 master 在 PR 审核之前发生了变化，开发人员就必须重新 rebase。这种方法的优点是，你可以更清晰地查看历史记录。

这里有一个链接，进一步讨论和解释了这一理念。在这里，您可以看到遵循此理念的项目的 Git 历史记录。

最大历史信息

另一个极端是，人们禁用快速合并，并强制创建合并提交。这种做法背后的理念是，历史记录是信息的来源，而创建快速合并会否认代码是在功能分支上创建的。他们常说：“线性历史记录是谎言”。

这里有一篇比较这两种方法并更倾向于后者的文章。这里有一个遵循第二种方法的项目。这里有一篇（部分）演讲，阐述了第二种哲学。

压缩合并

这是另一种保持历史线性的方法。本文将对此进行详细说明。

简而言之，压缩合并是指将整个合并源分支压缩为一个提交，该提交在合并目标分支之上创建，而无需创建合并提交。有些团队喜欢这样做，因为它可以精简 Git 历史记录。

权限

许多 Git 服务器允许在一定程度上限制权限。以下是一些使用场景：

• 假设您有一个名为live或prod的分支，每次提交新代码时，它都会自动部署到用户使用的实时生产环境中。您可能不希望每个人都能在这些分支上进行更改。
• 假设您想在主控中保持非常高的代码质量，那么人们就不可能绕过代码质量保证测量。

所以，在这两个例子中，你想要实现的基本上是限制某些分支的写入权限。以下是一些 Git 托管解决方案允许你实现此目的的方法：

• 几乎所有这些功能都允许您保护分支免受推送或合并等更改的影响。您可以将此权限授予一组选定的用户。
• 几乎每一个都允许您要求某些 CI/CD 管道成功后才能接受 PR。
• 有些功能可以让你设置某些分支只能由已接受的 PR 进行修改。这实际上强制了代码审查，非常酷。有时还可以要求特定人员批准 PR。

以下是一些更详细的链接：GitLab 关于分支保护的好处、 GitLab 文档关于只允许通过 PR （GitLab 语言中的合并请求）修改分支，以及GitHub 关于其分支保护功能

清理提交

首先，链接：完美 Pull 请求的剖析

许多团队都有规则来确定在什么情况下提交历史是“干净的”。首先，许多团队都有关于提交消息应该是什么样子的规则。一组非常流行的规则是这样的。另一篇关于规则的文章。

除此之外，我还听说过一些项目强制要求提交标题以模块名称或更改文件的名称开头（在这种情况下，标题长度通常没有那么严格的限制）。有些团队还要求必须包含正文。

一个非常流行的规则是：每次提交都必须编译成功，并且代码必须没有错误（最低要求：必须通过测试）。这样做的原因是，如果在某个时刻出现了回归问题，你可以通过git bisect（Link1，Link2）轻松找出是哪个提交导致了这个问题。

许多团队制定规则强制执行干净的历史记录是为了简化代码审查。当所有提交信息看起来相同时，它们可以更快地被处理。当所有提交都包含详细说明更改的正文时，审查者可以更快地掌握上下文。对于审查者来说，连续审查三个提交比审查一个包含三个不同逻辑更改的提交更容易。

然而，我们时不时都会进行“WIP”提交。我们会提交一些无法构建的提交，或者提交信息不美观等等。使用 Git，你可以随时使用 来回溯并清理你的历史记录git rebase --interactive。请参阅本指南，了解如何操作 Git 历史记录。

附言：Linus Torvalds清白历史

分支策略

在本节中，我将讨论创建什么分支以及何时创建分支的指南。

发布处理

如何处理发布取决于您是否需要支持多个软件版本。如果您始终只发布一个版本，然后再开发下一个版本，那么只需在主分支上添加标签即可。

如果您必须支持多个版本，请为每个版本创建一个发布分支。在这个分支上，您可以集成错误修复，并准备和发布更新。即使您只支持一个版本，发布分支也能发挥巨大作用。它们是执行软代码冻结的绝佳方式，在发布分支上，代码在错误查找期间不会更改，而在主分支上，可以全速添加新代码。

阅读有关发布分支的精彩指南。

有时你会检测到一个影响多个版本或主分支的 bug。针对这种情况，有多种不同的解决方法。

• Git Flow 建议从发布版本创建一个分支，并将修复提交合并到每个受影响的发布版本和开发分支中。

• 您可以手动为每个版本实施修复

• 当您修复了一个分支中的问题后，您可以选择提交到其他分支。

流行的分支策略

市面上有一些分支策略指南。Git Flow是互联网上最早撰写的详细分支指南之一，并因此广受欢迎。它读起来很有趣，但依我拙见，它对于分支策略来说有些过度了。这里有两个 Reddit 帖子[1] [2]，讨论了这个策略，并列举了它的缺点。

另一个非常流行的工作流程是基于主干的开发（TBD）。网站上有很多关于该工作流程细节的精彩文章。其中一些部分可以应用于其他工作流程。微软发布了一个Git 工作流程建议，与 TBD 非常相似，但阅读起来更短。我个人建议以那篇文章以及 TBD 为基础，作为你的工作流程的基础。

偶尔会有公司发明一种新的 Git 工作流程，给它起个好听的名字，然后以文章的形式发布。以下是我所知道的一些。

• Microsoft 的一个团队发布的Release Flow
• GitHub 流程
• GitLab 流程

然而，读完这些文章并不会让人感到很满足，因为你会发现它们大部分内容都和TBD一样。在我看来，这再次证明了TBD的必要性。

长期主题分支

主题分支应该保持较短的生命周期。这意味着理想情况下，分支和合并之间应该只间隔一两天。如果分支生命周期过长，主干代码库中的代码可能会发生变化，从而导致当前主干代码库与创建分支时的版本出现差异，从而引发问题。合并/变基会变得非常复杂。

• 防止长期分支的方法：
  • 减少分支/问题的范围（尝试将您要解决的问题拆分为更小的问题）
  • 使用功能切换 [1] [2] ... TL;DR：添加某种形式的切换（if通常是一个语句）来禁用和启用新代码。通过这种方法，新代码可以与旧代码并存，并且两者可以紧密协同发展。
  • 使用抽象分支，这是功能切换的一种变体。首先引入一个新的抽象，它包装了你想要更改的代码部分。然后，你将新代码作为该抽象的实现来实现，而团队的其他成员则使用旧的实现。

基于电子邮件的工作流程（Linux 内核）

Linux 内核是 Git 的诞生地。Linux 的首席开发者 Linus Torvalds 创建 Git 是因为他需要一个适合内核开发工作流程的源代码管理系统。该工作流程以邮件列表为中心。代码更改（“补丁”）通过邮件列表共享，并且没有像 GitHub 这样的中央 Git 服务器。这里是分布式 Git 工作流程的概述。这里有一个指南，解释如何将 Git 与电子邮件结合使用。

本工作流程指南到此结束。感谢您的阅读，欢迎给我反馈 :)