专业的 Git 工作流程：一个好的 Git 指南

Git 不仅可以通过版本控制来支持您的项目，还可以通过协作和发布管理来支持您的项目。 了解 Git 工作流模式如何帮助或阻碍项目将为您提供有效评估和调整项目 Git 流程的知识。

在本指南中，我将隔离常见 Git 工作流程中的软件开发流程模式。 了解这些知识将帮助您在加入、创建或发展开发团队时找到方向。 某些类型的项目或团队的优缺点将在我们探索的工作流示例中突出显示，以便您可以挑选适合您的场景的方法。

这不是使用 Git 的介绍。 那里已经有很棒的指南和文档。 如果您已经在应用程序开发团队中拥有经验并且遇到过工作流障碍、集成内爆或 git-tastrophes，那么您将从这个 Git 工作流指南中受益——这些模式可能会为将来如何避免这些情况提供一些启示。

合作

就 Git 流程而言，协作通常是关于分支工作流。 提前考虑如何将提交树交织在一起将帮助您最大限度地减少集成错误并支持您的发布管理策略。

集成分公司

与软件开发团队一起使用集成分支，这些团队致力于将一系列贡献部署到生产中作为单个实体。 这与专注于单独部署功能的团队相反。 通常团队可能希望做后者，但实际限制强加了一个将他们的工作分组的过程，团队最终会做前者，所以一定要检查你的实际 Git 使用情况，看看你是否会从使用这种类型的协作中受益图案。

当集成多个分支的风险高到足以保证测试整体的组合贡献时，此工作流模式是一个有用的过渡点。

一个集成分支通常由一个主要特性和几个要一起部署的较小贡献组成。 在您的开发团队的流程中放置一个集成分支（例如问答和验收测试）。 将次要提交推送到它以使其接近生产就绪状态，然后使用环境分支或发布分支（如下所述）为部署做好准备。

请注意，集成分支上的贡献需要合并到下一个发布阶段，然后才能将另一个主要功能合并到集成分支中 - 否则您将在不同的完成阶段混合功能。 这会抑制你释放准备好的东西的能力。

主题分支

如果将提交树保持在易于阅读或恢复单个功能的状态很重要，团队将希望使用主题分支。 主题分支表示提交可能会被覆盖（使用强制推送）以清理其结构并缩小为功能提交。

主题分支通常由个人贡献者拥有，但也可以是团队开发功能的指定空间。 其他贡献者知道这种类型的分支可以随时重写其提交树，并且不应尝试使其本地分支与其同步。

如果在 Git 工作流程中不使用主题分支，您将受限于推送到远程分支的提交。 强制将新的提交树推送到远程分支可能会激怒其他依赖与他们同步的分支的维护完整性的贡献者。

您可能已经在没有意识到的情况下使用此工作流模式，但值得在团队之间共享一组定义以加强他们背后的实践。 例如，您可能会发现在分支名称前加上分支创建者的首字母的约定有助于表明哪些是主题分支。 无论哪种方式，都由您的团队决定内部约定。

不要在公共存储库上使用主题分支，对于将本地分支与已重写提交树的主题分支同步的任何人，您都会导致无数冲突。

叉

使用这个源自 Github 的功能，开源项目蓬勃发展。 分叉为存储库维护者提供了一个强制网关，而不是直接推送到原始存储库分支，但更重要的是它促进了协作。 哇！

您可能会发现自己在创建私有存储库的分支也适合您的需求的情况下。 将 fork 存储库的贡献者的原始存储库设置为只读并使用拉取请求为您提供与开源社区体验相同的好处。 来自不同组织的团队可以使用分叉有效地工作，该分叉可以作为沟通和项目政策遵守的平台。

分叉工作流模式为团队提供了自己的空间，可以以他们习惯的任何方式工作，两个存储库之间有一个集成点——拉取请求。 在拉取请求描述中，过度沟通是必不可少的。 在发布拉取请求之前，团队有单独的沟通流，突出显示已经做出的决定将加快审查过程。

当然，fork 工作流程的一个好处是您可以将评论直接发送给原始存储库的贡献者，因为权限会向下级联。 从源存储库的角度来看，您可以控制在不再需要分叉时删除它们。

确保您使用的工具有助于分叉和拉取请求以利用此模式。 这些工具不仅限于 Github：其他流行的选择还有 Bitbucket 和 GitlLab。 但是还有相当多的其他 Git 工作流托管服务将具有这些功能（或类似功能）。 选择最适合您的服务。

不要为团队的每个成员使用私有存储库的分支。 众多的分叉存储库可能使多个成员难以在同一个功能分支上进行协作，并且由于移动部件的数量庞大，使所有这些存储库保持同步可能会变得容易出错。 开源项目的核心团队成员具有对原始存储库的推送访问权限，从而减少了这种开销。

克隆

一个常见的外包策略是在一个项目中拥有可以由多个软件开发人员担任的贡献“席位”。 由外包公司管理他们的资源管道以交付合同工时，他们面临的问题是如何为每个客户的项目加入、培训和维护他们的开发人员库。

使用项目存储库的克隆为外包团队提供了一个孤立的培训和交流平台，以管理他们的贡献、执行政策和利用知识共享——所有这些都在客户开发团队的监视下进行。 一旦认为贡献符合标准并准备好用于主存储库，就可以将其推送到源存储库远程分支之一并照常集成。

一些项目对遵循其编码约定和定义的 Git 工作流标准以贡献其存储库有很高的期望。 在您掌握诀窍之前，在这种环境中工作可能会让人望而生畏，因此请作为一个团队一起工作以优化双方的时间。

不要在未经客户许可的情况下创建客户存储库的托管副本，您可能会违反合同协议，请预先确认这种做法将有利于客户的项目。

发布管理

从协作到发布之间的步骤将从每个团队的开发过程中的不同点开始。 通常，您不希望使用多个版本管理 Git 模式。 您希望拥有最简单的工作流程，使您的团队能够有效地交付。

环境分支

您的软件开发过程可能会受到多个环境的支持，以帮助在部署到生产之前进行质量保证。 环境分支模拟了这个过程的各个阶段：每个阶段对应一个分支，贡献在管道中流经这些阶段。

使用这些流程运行的团队通常会为管道中的每个阶段设置应用程序环境，例如“QA”、“Staging”和“Production”。 在这些情况下，基础设施已经到位，以支持负责签署功能或贡献的人员，他们对生产就绪的意义（例如，探索性测试、质量保证、验收测试）进行了验证，然后再将其转移到下一个人的阶段。 这为他们提供了根据自己的要求进行部署、测试和评估的地方，并使用 Git 工作流来记录其通过签核隧道的旅程。

对于可以将发布作为一个单元工作的小型团队来说，在流程的每个阶段都有一个分支是可以的。 不幸的是，这样的管道很容易成为瓶颈或聚集并留下空隙。 它将您的 Git 进程与您的基础设施耦合在一起，当功能需求增加并且两个进程都需要扩展时，这可能会导致问题。

不要在不首先考虑其他模式的长期利益的情况下使用此模式。

发布分支

在连续冲刺中将一系列贡献作为一个单元推送到其生产应用程序的团队可以找到发布分支的合适选择。

在发布分支上对一系列接近“生产就绪”的提交进行了小错误修复。 在将其提交树移动到发布分支之前，使用集成分支来组合和测试功能。 将发布分支的职责限制为在部署到生产应用程序之前作为最终检查。

发布分支与环境分支的不同之处在于它们的生命周期很短。 发布分支仅在需要时创建，并在其提交树部署到生产环境后销毁。

尽量防止将发布分支与您的软件开发路线图耦合。 限制自己遵循预先确定的计划会延迟发布版本，直到所有计划的功能都准备好生产。 在创建发布分支之前不为路线图分配版本号可以缓解这些类型的延迟，方法是允许将生产准备就绪的功能放入发布分支并进行部署。

请使用版本号命名约定作为发布分支名称，以明确已将哪个版本的存储库部署到生产环境中。

部署主分支而不是发布分支。 为了鼓励在与主分支合并之前对发布分支进行小修复，请在主分支上使用 Git 挂钩在发生合并后触发以自动将更新的提交树部署到生产中。

在给定的时间只允许一个发布分支存在确保您将避免保持多个发布分支彼此同步的开销。

不要使用多个团队在同一个存储库上工作的发布分支。 尽管发布分支是短暂的，但如果最终检查它花费的时间太长，那么它会阻止其他团队发布。 一个团队捎带另一个团队的发布分支很可能会引入错误并导致两个团队的延迟。 看看下面的带时间戳的发布模式，它对更多和更多的贡献者来说效果更好。

时间戳发布

具有基础设施限制的应用程序通常在低流量期间安排其部署。 如果您的项目面临准备部署的常规功能队列，那么您可能会从使用时间戳发布中受益。

带时间戳的发布依赖于部署过程来自动将时间戳标记添加到部署到生产中的主分支上的最后一次提交。 主题分支用于在合并到主分支以等待部署之前将功能通过开发过程。

时间戳标签应该包含一个实际的时间戳和一个标签，以表明它代表一个部署，例如： deployed-201402121345 。

在主分支的提交树中以时间戳标记的形式包括部署元数据，将帮助您调试发布到生产应用程序中的回归。 负责追查问题原因的人员不太可能对部署到生产应用程序中的每一行都非常了解。 在最后两个标签上运行git diff命令可以快速给出最后部署的提交以及可以帮助解决问题的提交作者的快照。

带时间戳的分支比表面上出现的要多。 记录排队功能部署的简单机制需要大量的良好流程来驱动它。 这个过程是一个可以扩展的过程，也可以与一小部分贡献者一起很好地工作。

为了让这个 Git 工作流模式真正有效，它需要 master 分支始终是可部署的。 这对您的团队可能意味着不同的事情，但基本上所有提交都必须经过您的项目开发过程，然后才能进入主分支。

登陆主分支的新提交每天会发生多次。 这是已经通过开发过程并且在此期间没有与主分支同步的主题分支的问题。 不幸的是，当错误处理合并冲突时，这种情况可能会在主分支中引入回归。

如果主题分支和主分支之间确实出现合并冲突，那么在更新远程主分支之前，应该与您的团队讨论引入新错误的风险。 如果对可能发生回归有任何疑问，则可以通过质量保证过程放回主题分支，并解决合并冲突。

为了减少集成错误，在存储库的相关部分工作的开发人员可以协作确定何时最好地将他们的主题分支与主分支合并和同步。 集成分支也可以很好地解决来自相关主题分支的冲突——这些应该在被合并到主分支待部署的队列中之前通过测试过程。

有许多贡献者的软件开发项目必须以实用和有效的方法处理协作和发布管理过程。 我们从使用时间戳发布获得的提交树上的额外元数据是指向准备响应生产问题的团队的远见的指针。

版本分支

如果您的存储库不仅在生产中运行，而且其他人用于他们自己的托管应用程序，那么使用版本分支可以为您的团队提供平台来支持那些不或不能保持在应用程序开发前沿的用户.

使用版本分支的存储库将有一个应用程序的每个次要版本的分支。 主要、次要和补丁版本在语义版本控制文档中进行了说明。 版本分支通常遵循包含“稳定”一词的命名约定，并从应用程序版本中删除补丁号：例如2-3-stable以使其目的和可靠性对最终用户显而易见。

Git 标签可能会应用到应用程序的补丁版本号，但版本分支并不是那么精细。 版本分支将始终指向受支持的次要版本的最稳定提交。

当出现安全补丁或需要向后移植功能时，将适用于您支持的旧应用程序版本所需的提交放在一起，并将它们分别推送到您的版本分支。

除非您支持多个版本的存储库，否则不要使用版本分支。

概括

当您的团队规模发生变化，或者您的项目通过持续评估开发其流程时，不要忘记评估您的 Git 流程。 使用本教程中的模式作为起点，帮助您走上 Git 工作流程正义的道路。

本指南中的模式可以帮助您在调整分布式版本控制系统以适应您的工作方面具有一定的远见。 如果您想了解 Git 工作流程，请务必查看 Gitflow、Github Flow，以及最重要的是令人惊叹的 git-scm 文档！