小型团队的 Git 分支

以下是我个人在开源项目以及我管理的任何小型团队中都会使用并鼓励采用的一种实践方法。我见过它的主要元素以几种不同的名称出现，例如：短期特性分支流程、GitHub 流程（不要与 GitFlow 混淆）和特性分支工作流等等。多年来，我曾与不同的团队合作，实践过所有这些方法中我喜欢的特性，现在我将介绍我发现最适合 5-12 人左右小型团队的最终流程。

受保护的主分支

为了支持持续交付，任何人都不应该拥有直接推送分支的权限。如果您在 GitHub 上进行开发，当您创建版本时（希望发布频率很高且高度自动化），master该分支的最新标签将被部署。

一个问题，一个分支，一个 PR

你们在跟踪未来功能和当前 bug 方面做得非常出色，对吧？。简单来说，问题（issue）是指可以合并到主分支并部署而不会破坏任何现有功能的明确工作内容。它可以是新功能、按钮组件更新或 bug 修复。

作者对主分支和版本发布问题的图示。

每个问题创建一个生命周期较短的分支有助于确保最终提交的拉取请求不会过大，从而避免变得难以管理且难以仔细审查。“短”的定义取决于团队或项目的开发速度：对于开发商业应用的小型团队（例如初创公司），从创建问题分支到提交拉取请求的时间可能不会超过一周。而对于像OWASP WSTG这样依赖志愿者在繁忙日程中灵活工作的开源项目，分支的生命周期可能从几周到几个月不等，具体取决于贡献者。总而言之，应力求在尽可能短的时间内完成迭代。

以下是实际操作示例。对于名为“(#28) 添加用户设置页面”的问题，请从以下位置检出一个新分支master：

# Get all the latest work locally
git checkout master
git pull
# Start your new branch from master
git checkout -b 28/add-settings-page

着手处理这个问题，并定期合并代码master以修复并避免其他冲突：

# Commit to your issue branch
git commit ...
# Get the latest work on master
git checkout master
git pull
# Return to your issue branch and merge in master
git checkout 28/add-settings-page
git merge master

你可能更倾向于使用变基（rebase）而不是合并（merging）master。这恰好也是我个人的偏好，但我发现人们通常更难理解变基的工作原理，而不是合并。交互式变基很容易引入令人困惑的错误，而且重写历史记录本身就容易让人感到困惑。由于我一直致力于降低开发人员的认知负荷，因此我建议使用合并策略。

当问题处理工作准备好提交 PR 时，请向 [此处应填写提交 PR 的链接] 提交请求master。系统会运行自动化测试。团队成员会审核工作（如果您使用 GitHub，他们可以使用内联评论和建议）。根据项目情况，您可能还需要部署预览版本。

一切检查完毕后，PR 将被合并，问题将被关闭，分支将被删除。

保持清洁

我见过一些会破坏这种流程的常见陷阱，包括：

1. 从其他特性/问题分支创建特性分支，这是组织和优先级排序不合理的结果。为了避免冲突和依赖关系混乱，请始终从最新的分支创建分支master。
2. 让问题分支多存在一段时间，会导致范围蔓延，产生庞大而混乱的 PR，审查起来既费时又费力。务必确保分支的范围严格限定在它们应该解决的单个问题上。
3. 不要删除已合并的分支。没有理由保留它们——所有工作都已经完成master。不删除过时的或已经合并的分支可能会造成混乱，并使区分新分支变得更加困难。

如果你觉得这个方法适合你，或者你有什么补充，请在评论区告诉我！