GitLab版本控制与协作最佳实践

2020 版本控制最佳实践

增强团队协作的五种简单方法

• 确定合适的分支策略
• 频繁进行小的变更
• 编写描述性的提交信息
• 使用分支进行开发
• 进行常规的代码审查

行业的快速变化以及客户对新功能的需求不断增加，可能导致团队孤岛工作。应用程序开发需要速度和迭代，因此无缝协作是交付业务价值的必要条件。团队转向版本控制来简化协作并打破信息孤岛。版本控制协调软件项目中的所有更改，有效地跟踪源代码、文件和元数据的更改，以帮助团队快速协作并共享反馈，从而导致立即可行的变更。

应用版本控制的团队可以无缝地协调工作、查看更改和管理交付，从而帮助他们专注于解决问题和交付价值。

版本控制和协作不只是跟踪更改，还包括以下实践：

• 使开发团队能够在分布式和异步环境中工作
• 管理代码与工件的更改和版本
• 启用代码审查和其他资产
• 跟踪讨论变更的批准
• 解决合并冲突和相关的集成问题

版本控制入门可能是一项艰巨的任务，尤其是在面对瞬息万变的环境时。该电子书介绍了五个最佳实践，以帮助开发团队加强协作以进行迭代使用新功能并使用Git交付业务价值。

1.确定合适的分支策略

当来自不同专业和教育背景的团队成员一起工作时，工作流程可能会出现冲突。为了避免混乱的发展，领导者应确定并广泛地传达一种分支策略。确定分支工作流程取决于几个因素，包括团队规模，经验水平，扩展要求和行业限制。尽管团队可以选择遵循既定的工作流程，但也可以根据特定需求创建自定义的工作流程。无论选择哪种策略，都必须将工作流程传达给团队并在必要时提供培训，这一点很重要。

当每个人在同一工作流程中和谐地工作时，覆盖代码或破坏主代码的风险就较小。此外，由于每个人都熟悉开发和部署过程，因此团队成员可以轻松地为彼此的工作做出贡献。清晰，简洁的分支策略设定了合并新代码并推进项目的节奏。这种节奏感有助于团队成员安排会议并管理截止日期和工作量。

常见的工作流与影响

集中式工作流程集中式工作流程包括一个存储库和一个主分支。团队不使用任何其他分支来进行开发，因此存在覆盖变更的高风险。

尽管这种类型的工作流中没有协作节奏，但它可以在小型团队（少于5个开发人员）中很好地工作，这些团队使用良好的沟通来确保两个开发人员永远不会尝试同时处理同一代码。

功能分支功能分支意味着为每个需要添加的功能创建一个新分支。每个需要处理功能的人都将代码提交到功能分支。

功能分支连接了各个团队，因为它需要更多的代码审查，推送规则，代码批准者和更广泛的测试集。

GitFlowGitFlow是功能分支的基线版本。使用GitFlow进行开发包含一个主分支和一个单独的开发分支，以及功能，版本和修补程序的分支。发展发生在开发分支，移至发布分支，并合并到主分支。

任务分支开发Task-branch GitLab Flow是此类开发的一个示例，它将驱动功能的开发和问题跟踪。GitLab Flow通过使用单独的专用分支来配置测试，预生产和生产等多种环境，以确保在所有环境下都对所有内容进行了测试。

任务分支的开发设定了非常快的速度，迫使团队成员将需求分解为小块价值，这些价值将通过任务分支交付。这种类型的工作流嵌入了协作实践，例如代码片段，代码审查和单元测试。此外，如果测试失败，团队成员可以共同努力，找出问题所在。

2.频繁进行小的变更

只有在一个大型的，即将完成的项目可用时，团队才能养成承诺的习惯，他们认为完美是交付的前提。但是，如果不采取更小的步骤并提供更简单的功能，团队就有冒险花费时间来开发错误的功能或朝错误的方向发展。寻找将项目简化为小步骤，然后频繁提交以完成更大目标的方法。

旨在实现业务价值并满足客户需求的最有效的软件开发方法是:每当您具有一组有效的测试和代码时就进行提交。

频繁提交的文化确保每个人都知道队友正在做什么，因为每个人都可以看到代码存储库。即使尚未准备好进行审核，团队也应经常推送到功能分支，因为在功能分支中共享工作或合并请求会阻止队友重复工作。在完成之前共享工作还可以促进讨论和反馈，从而有助于在审查之前改进代码。将工作分解为单独的提交为开发人员和其他团队（例如质量和安全性）提供了上下文，这些团队稍后将审查代码。较小的提交可以清楚地确定功能的开发方式，从而可以轻松地回滚到特定的时间点或还原一个代码更改而无需还原几个不相关的更改。

3.编写描述性的提交信息

提交消息应该反映意图，而不仅仅是提交的内容。很容易看到提交中的更改，因此提交消息中应说明为什么进行了这些更改。

建立提交消息约定对确保团队之间的一致性并减少混乱和误解很重要。

良好提交消息的示例是：“合并模板以减少用户视图中的重复代码。” “更改”，“改进”，“修复”和“重构”等字眼不会在提交消息中添加太多信息。例如，将“改进XML生成”更好地写为“在XML生成中正确地转义特殊字符”。

描述性的提交消息可以提高透明度并提供对进度的洞察力，以便团队成员，客户和未来的贡献者可以了解开发过程。在进行代码审查时，提交消息可帮助团队成员跟踪迭代并确定自发布，讨论或需求变更以来进行了哪些更改。详细的提交消息还可以帮助质量和安全团队在检查代码时识别出所关注的区域并还原特定的更改。此外，当开发人员编写详细的提交消息时，它可以防止队友重复工作，限制延迟并帮助项目更稳定地进行。

4.使用分支进行开发

在分支中进行开发就像在其当前状态下为某个分支（通常是主分支）创建快照一样。

使用分支，团队成员可以进行更改而不会影响主代码库。更改的历史记录将在分支中进行跟踪。代码准备就绪后，可以将其合并到master分支中。

在分支中进行编码可以使组织的开发方法更有条理，并使工作作为独立的草稿而不与master中经过测试的稳定代码保持一致。

在分支中进行编码使团队成员能够尝试并找到针对复杂问题的创新解决方案。团队可以发挥创造力而无需担心主分支不稳定。此外，团队成员可以协作以确保解决方案在将其合并到master分支之前，可以很好地工作。运营，质量和安全团队可以在部署代码之前对其进行检查，以确保每个人都具有可见性，并有机会在发布产品之前讨论想法并提出任何潜在问题。

5.进行常规的代码审查

实施常规代码审查的文化可确保持续改进并防止代码不稳定。欢迎所有团队成员审查任何人的代码并提出建议。一旦有任何代码要审查，团队成员应将代码审查分配给熟悉项目的个人，同一团队的成员或领域专家。

进行代码审查时，团队成员应：

• 说明需要进行哪些更改（例如，修复错误，改善用户体验，重构现有代码）。
• 如果有小的，非强制性的改进，则在前缀注释中添加“Not blocking”，以帮助作者理解该建议是可选的，可以立即或在其他迭代中解决。
• 提供其他实现，但假设作者已经考虑过（例如，“您在这里使用自定义验证器有什么想法？”）。
• 尝试彻底减少迭代次数。
• 确定在解决问题的同时简化代码的方法。

代码审查是对解决方案和实现的第二意见，并且是寻找错误，逻辑问题或未发现的极端情况的另一双眼睛。代码审查有助于缓解在发布时又带来繁重问题的挑战。审查解决方案并提供建议可以帮助团队成员一前一后地进行审查。

通过协作进行代码审查，团队成员可以学习不同的编码实践，工作流技术以及解决问题的新方法，从而提高了创新和效率，并减少了知识孤岛。