本文概述
Git不仅可以通过版本控制来支持你的项目, 而且还可以通过协作和发布管理来支持你的项目。了解Git工作流程模式如何帮助或阻碍项目, 将为你提供知识, 以有效地评估和调整项目的Git流程。
在本指南中, 我将隔离常见Git工作流程中的软件开发过程模式。了解这些知识将帮助你在加入, 创建或发展开发团队时找到方向。在我们探索的工作流示例中, 将突出显示某些类型的项目或团队的利弊, 以便你可以选择适合自己的方案的方案。
这不是使用Git的介绍。那里已经有出色的指南和文档。如果你已经在应用程序开发团队中拥有丰富的经验, 并且遇到过工作流遇到的障碍, 集成内爆或git-tastrophe, 你将从该Git工作流指南中受益。这些模式可能为将来如何避免这种情况提供一些启示。
合作
就Git流程而言, 协作通常是关于分支工作流程的。提前考虑如何将提交树交织在一起, 将有助于你最小化集成错误并支持你的发布管理策略。
整合处
与软件开发团队一起使用集成分支, 这些团队致力于将一组贡献作为单个实体部署到生产中。这与专注于单独部署功能的团队相反。通常, 团队可能希望进行后者, 但实际的限制会迫使他们将努力归为一组, 而团队最终会进行前者, 因此, 请务必查看你的实际Git使用情况, 以查看你是否将从使用这种类型的协作中受益图案。
当整合多个分支机构的风险足够高以至于需要测试合并的总体贡献时, 此工作流模式是一个有用的切入点。
集成分支通常包含一个主要功能和几个较小的组件, 可以一起部署。在你的开发团队的流程(例如, 问答和验收测试)中设置一个集成分支。将次要提交推送到它, 使它接近生产环境, 然后使用环境分支或发行分支(如下所述)为部署做好准备。
请注意, 在将另一个主要功能可以合并到集成分支之前, 需要将集成分支上的贡献合并到下一个发行阶段-否则, 你将在完成的不同阶段混合功能。这将抑制你释放已准备好的东西的能力。
主题分支
如果将提交树保持在易于阅读的状态或恢复单个功能的状态很重要, 则团队将希望使用主题分支。主题分支表示可以重写(使用强制推送)提交以清理其结构, 并将其缩小为功能提交。
主题分支通常由个人贡献者拥有, 但也可以是团队用来开发功能的指定空间。其他贡献者知道, 此类分支可以随时重写其提交树, 并且不应尝试使其本地分支与其保持同步。
在你的Git工作流程中不使用主题分支的情况下, 你只能坚持推送到远程分支的提交。强制将新的提交树推送到远程分支可能会激怒其他贡献者, 这些贡献者依赖于与他们同步的分支的维护的完整性。
你可能已经在使用该工作流程模式而没有意识到它了, 但是值得在团队之间共享一组定义以加强其背后的实践。例如, 你可能会发现在分支名称前加上分支创建者的缩写的约定有助于表明哪些是主题分支。无论哪种方式, 都取决于你的团队来决定内部惯例。
请勿在公共存储库上使用主题分支, 对于将其本地分支与重写了提交树的主题分支同步的任何人, 都会造成许多冲突。
叉子
使用此Github起源的功能, 开源项目会蓬勃发展。该分叉为存储库维护者提供了一个强制网关, 可以直接将其推送到原始存储库分支, 但更重要的是, 它可以促进协作。哇！
你可能会遇到这样的情况：创建私有存储库的分支也适合你的需求。将fork存储库的参与者的原始存储库设置为只读, 并使用pull请求进行滚动, 将为你带来与开源社区一样的收益。来自不同组织的团队可以使用fork进行有效工作, fork可以成为沟通和遵守项目政策的平台。
fork工作流模式为团队提供了自己的空间, 使他们能够以任何习惯的方式工作, 并且在两个存储库之间只有一个集成点-拉取请求。在拉取请求描述中必须进行通信。在发出拉取请求之前, 团队已经有单独的交流流, 并且突出显示已经做出的决定将加快审核过程。
当然, fork工作流的一个好处是, 随着权限的降低, 你可以将注释定向到原始存储库的贡献者。从原始存储库的角度来看, 你可以控制删除不再需要的分叉。
确保你使用的工具便于派生和拉取请求以利用此模式。这些工具不仅限于Github：其他流行的选择是Bitbucket和GitlLab。但是还有很多其他具有这些功能(或类似功能)的Git工作流托管服务。选择最适合你的服务。
请勿为团队的每个成员使用私有存储库的分支。众多的分支存储库可能使多个成员难以在同一个功能分支上进行协作, 并且由于移动部件的数量众多, 使所有这些存储库保持同步可能容易出错。开源项目的核心团队成员具有对原始存储库的推送访问权限, 从而减少了此开销。
克隆
常见的外包策略是在可以由多个软件开发人员填补的项目上拥有”席位”。由外包公司来管理他们的资源管道以交付合同规定的小时数, 他们面临的问题是如何为每个客户的项目注册, 培训和维护开发人员池。
使用项目存储库的副本为外包团队提供隔离的培训和交流平台, 以供外包团队管理其贡献, 执行策略并利用知识共享, 而这一切都是在客户开发团队的监视下进行的。一旦认为贡献符合标准并准备好用于主存储库, 就可以将其推送到原始存储库的一个远程分支中, 并照常进行集成。
一些项目对遵循其编码约定和定义的Git工作流标准以对其存储库做出贡献寄予很高的期望。在你了解这些绳索之前, 在这种环境下工作可能会令人生畏, 因此, 作为一个团队共同努力, 以优化双方的时间。
未经客户的许可, 请勿创建客户资源库的托管副本, 否则你可能会违反合同协议, 请先确认此做法将使与客户的项目受益。
发布管理
从协作到发布之间的步骤将在每个团队的开发过程中的不同点开始。通常, 你不想使用多个发布管理Git模式。你希望拥有最简单的工作流程, 以使你的团队能够有效交付。
环境部门
你的软件开发过程可能会受到多种环境的支持, 以帮助确保质量, 然后再将其部署到生产中。环境分支模仿了此过程的各个阶段：每个阶段都对应一个分支, 并且贡献通过管道流经这些分支。
运行这些流程的团队通常在管道的每个阶段都设置了应用程序环境, 例如” QA”, ” Staging”和” Production”。在这些情况下, 基础结构已经到位, 以支持负责在其功能上签字或准备投入生产(例如, 探索性测试, QA, 验收测试)的人员, 然后将其移交给下一个人员。阶段。这使他们可以根据自己的要求部署, 测试和评估自己的位置, 并使用Git工作流程记录其通过签核通道的过程。
对于可以朝着一个单位发布的小型团队, 在流程的每个阶段都有一个分支是可以的。不幸的是, 这样的管道很容易成为瓶颈或束缚, 并留下空白。它会将你的Git流程耦合到你的基础架构, 这会在功能需求增加且两个流程都需要扩展时引发问题。
在不首先考虑其他模式的长期利益的情况下, 请勿使用此模式。
发布分支
一个团队在连续的sprint中将贡献的集合作为一个单元推送到他们的生产应用程序中, 可以发现发布分支非常适合。
在发布分支上, 对接近”生产就绪”提交的集合进行了较小的错误修复。在将其提交树移至发布分支之前, 请使用集成分支来组合和测试功能。将发布分支的职责限制为在部署到生产应用程序之前进行最终检查。
发布分支与环境分支的不同之处在于它们的寿命很短。仅在需要时创建发行分支, 并在将其提交树部署到生产中后销毁发行分支。
尝试防止将发行分支耦合到软件开发路线图。限制自己遵循预定计划会延迟部署发行版, 直到所有计划的功能均已准备就绪。通过允许将准备就绪的功能部件放入发布分支并进行部署, 在创建发布分支之前不为路线图分配版本号可以减轻这些类型的延迟。
对于发行分支名称, 请使用版本号命名约定, 以使明显的版本库已部署到生产环境中。
部署master分支而不是release分支。为了鼓励在与master分支合并之前对release分支进行较小的修复, 请在master分支上使用Git挂钩在合并发生后触发, 以将更新的提交树自动部署到生产环境中。
在给定的时间只允许一个发布分支存在, 可以确保避免多个发布分支之间保持同步的开销。
不要将发布分支与在同一个存储库上工作的多个团队一起使用。即使发布分支的寿命很短, 但是如果最终检查花费的时间太长, 那么它将阻止其他团队发布。一个团队拥护另一个团队的发布分支很可能会引入错误并导致两个团队的延迟。请查看下面带有时间戳记的发布模式, 该模式对于大量贡献者和群体贡献者更好。
带时间戳的版本
具有基础结构限制的应用程序通常在流量较低的时期安排其部署。如果你的项目面临准备好要部署的常规功能队列, 那么你可以从带有时间戳的发行版中受益。
带时间戳的发行版依赖于部署过程, 以将时间戳标记自动添加到已部署到生产中的master分支上的最后一次提交。在合并到主分支以等待部署之前, 主题分支用于在开发过程中放置功能。
时间戳记标签应包括实际时间戳记和标签, 以指示它代表部署, 例如：deployed-201402121345。
在master分支的提交树中以timestamp标记的形式包括部署元数据, 将帮助你调试发布到生产应用程序中的回归。负责寻找问题根源的人不太可能对部署到生产应用程序中的每条线都了解很多。在最后两个标签上运行git diff命令可以快速给出最近部署的提交以及谁可以帮助解决问题的提交作者的快照。
带时间戳的分支比其表面上显示的要多。记录排队功能的部署的简单机制需要大量令人惊奇的良好过程来驱动它。这个过程可以扩展, 并且可以与一小部分贡献者一起很好地工作。
为了使此Git工作流程模式真正有效, 它需要master分支始终可部署。对于你的团队来说, 这可能意味着不同的事情, 但是基本上所有提交都必须经过你的项目开发过程, 然后才能进入master分支。
每天要多次出现在master分支上的新提交。对于已经通过开发过程并且在此期间未与master分支同步的主题分支, 这是一个问题。不幸的是, 当合并冲突处理不当时, 这种情况可能会将回归引入master分支中。
如果在主题分支和主分支之间确实发生合并冲突, 那么在更新远程主分支之前, 应与你的团队讨论引入新错误的风险。如果不确定是否会发生回归, 则可以将主题分支放回质量保证流程中, 并解决合并冲突。
为了减少集成错误, 致力于存储库相关部分的开发人员可以在何时最好地将其主题分支与master分支合并和同步方面进行协作。集成分支也可以很好地解决来自相关主题分支的冲突-在合并到要部署的主分支上的队列之前, 应对这些冲突进行测试流程。
具有许多贡献者的软件开发项目必须使用实用且有效的方法来处理协作和发布管理过程。通过使用带有时间戳的发行版, 我们在提交树上获得的其他元数据是对准备响应生产问题的团队具有远见的指针。
版本分支
如果你拥有的存储库不仅可以在生产环境中运行, 而且可以供其他人用于自己的托管应用程序, 则使用版本分支可以为你的团队提供一个平台, 以支持那些无法或不能始终站在应用程序开发的前沿的用户。
使用版本分支的存储库将为应用程序的次要版本提供一个分支。主要版本, 次要版本和修补程序版本在语义版本说明文档中进行了说明。版本分支通常遵循命名约定, 以包含单词” stable”, 并从应用程序版本中删除补丁号： 2至3稳定, 以使最终用户清楚地了解其目的和可靠性。
可以将Git标签应用于应用程序的补丁版本号, 但是版本分支的粒度并不那么精细。版本分支将始终指向支持的次要版本的最稳定提交。
当出现安全补丁或需要向后移植功能时, 请将为支持的较旧应用程序版本工作所需的提交放在一起, 然后将它们分别推送到你的版本分支中。
除非你支持存储库的多个版本, 否则请勿使用版本分支。
摘要
当你的团队改变规模, 或者你的项目通过持续评估来开发其流程时, 也不要忘记评估你的Git流程。使用本教程中的模式作为起点, 以帮助你指导Git工作流程的正当化。
本指南中的模式可以帮助你有预见性地使你适应分布式版本控制系统以为你工作。如果你想阅读Git工作流程, 请务必查看Gitflow, Github Flow以及最重要的git-scm文档！
