选择简单的 Git 分支模型

对于第一个团队项目，应保持分支模型简洁：main 始终保持可部署状态，每项任务对应一个生命周期较短的功能分支。如果团队正在开发一个 React 落地页和一个结账 API，可以将工作分别放在 feature/pricing-page 和 feature/create-checkout-session 中，而不是使用一个共享的开发分支。这样的隔离方式可以让两名开发者并行工作，同时避免未完成的代码相互混杂。在项目尚未形成真正需要这些分支的发布流程之前，不要添加 develop、release 或 hotfix 分支。

在第一个工单开始之前，就应统一工作流。明确记录以下规则：main 只能通过拉取请求接收变更，功能分支从 main 创建，合并后的分支必须删除。例如，密码重置任务应依次经历从 issue 到功能分支、代码审查，再到 main 的流程，并且不得直接推送到共享分支。这些规则能将版本控制变成可预测的团队习惯，而不是一组个人偏好。

设置 main 和分支命名规则

在任何人创建拉取请求之前，先在代码仓库设置中保护 main。要求自动化检查通过并至少获得一项批准，同时禁止强制推送，以免本地错误改写团队共享的历史记录。对于四人团队来说，一名审查者通常是一个切实可行的起点；对于敏感的支付或身份验证代码，则应提高审批要求。将规则写入 CONTRIBUTING.md 并保持其公开可见，这样新成员无需私下询问即可遵循。

使用能够体现用途的分支名称，并在可用时加入任务 ID。例如：feature/42-reset-password、fix/57-cart-total、docs/api-setup 和 chore/update-node。与 John'sNewBranch 或 work 之类的名称相比，使用小写字母和连字符的名称更便于在终端输出和拉取请求列表中快速查看。合并后删除分支，使远程分支列表反映当前活跃的工作，而不是积累数月未使用的实验分支。

从已更新的 main 创建功能分支

开始编码前，先与远程仓库同步，并从当前的 main 分支创建功能分支。运行 git switch main，然后运行 git pull --ff-only origin main，再使用 git switch -c feature/42-reset-password 创建分支。--ff-only 选项可防止 Git 在此次更新期间悄悄创建意外的合并提交。从最新的基础分支开始，可以降低一个为期三天的任务立即与昨天合并的变更发生冲突的可能性。

编辑文件前，使用 git status 和 git log --oneline --decorate -5 检查分支名称和起始位置。如果任务已经有现成分支，先使用 git fetch origin 获取更新，并将其与 origin/main 比较，而不是创建名称相似的第二个分支。对于落后一个提交的分支，在确认本地工作已提交后，可以使用 git rebase origin/main 进行更新。除非团队已就由此产生的历史重写达成一致，否则不要对多个队友正在积极使用的分支执行 rebase。

创建小而易于审查的 Git 提交

提交应小到让另一名开发者能在一两分钟内理解每项变更。一个结账功能可以将数据库迁移、接口和表单分别放在三个提交中，而三行的拼写错误修复通常应保留为一个提交。每次推送前运行相关测试，因为一个易于审查但无法通过现有测试套件的提交，仍会拖慢团队进度。不要将生成文件、本地环境密钥和无关的格式化变更带入分支。

使用祈使语气撰写提交消息，例如 Add password reset validation 或 Fix cart total rounding。每条消息都应说明变更意图，而差异内容则展示实现细节。在本地检查结果后，使用 git push -u origin feature/42-reset-password 发布新分支。如果在审查前发现错误，请在本地 amend 或 squash；一旦审查者开始发表评论，应优先创建新的修正提交，以便保留可追溯的讨论过程。

发起 Pull Request 并运行 CI

分支准备好接受审查后，应立即发起 pull request，即使变更仅涉及六个文件。将 main 设为目标分支，关联任务，描述变更内容，并记录确切的验证命令，例如 npm test 和 npm run lint。对于登录表单变更，应包含受影响的路由、键盘行为、错误状态截图，以及审查者必须执行的任何迁移步骤。只有在希望先获得早期反馈、之后再请求批准时，才将请求标记为 draft。

使用持续集成，在 pull request 上运行团队要求开发者在本地执行的相同质量检查。一个实用的初始流水线可以安装依赖、运行单元测试、执行 lint，并分四个独立且可见的步骤构建应用程序。如果构建因遗漏 package-lock 文件而失败，应修复分支并再次推送，而不是要求审查者忽略红色检查结果。CI 是一种信号，不能替代代码审查：测试可能通过，但按钮仍然无法访问，或 API 响应暴露私有数据。

审查、合并并保持 Main 稳定

应将审查意见视为对共享设计的改进，而不是对作者的投票。如果审查者要求对价格字段进行服务端验证，就更新代码，针对 -1 这样的负值添加专门测试，并通过提交或文件位置进行回复。在 pull request 中解决相关问题，让最终历史记录实现为何发生变化。若第一位审查者的意见揭示了有关安全性、数据丢失或公共 API 行为的更广泛问题，应邀请第二位审查者参与。

选择一种合并策略并始终贯彻执行。对于第一个项目，将包含五次提交的功能分支压缩合并为一个描述性提交，可以让 main 分支保持清晰易读；而需要详细追溯发布历史的团队，则可以保留各个独立提交。只有在所有必需检查均通过、审批仍然有效，并且根据仓库规则该分支没有落后于 main 分支时，才能执行合并。合并后，在开始下一项任务前，先宣布任何需要手动执行的部署或迁移步骤。

解决冲突并清理分支

当你工作期间 main 发生变化时，请在请求最终审批前更新分支。获取远程更新，运行 git rebase origin/main，并逐个文件解决冲突；例如，保留最新的共享按钮组件，同时保留你新增的结账行为。编辑完冲突后，对该文件运行 git add，然后运行 git rebase --continue，接着重新运行测试。如果冲突变得难以理清，git rebase --abort 可以将分支恢复到 rebase 之前的状态，这样你可以在不丢失已提交工作的情况下寻求帮助。

拉取请求合并后，使用 git push origin --delete feature/42-reset-password 删除远程分支，并使用 git branch -d feature/42-reset-password 删除本地副本。然后运行 git switch main 和 git pull --ff-only origin main，再选择下一项任务。如果仍有未完成的工作，请从更新后的 main 创建一个新分支，而不要继续使用已经合并的分支。一周后，仓库应当呈现出稳定的 main 分支、少量活跃任务，以及能够解释每项面向用户的变更的提交历史。

相关文章

延伸阅读

Git

版本控制

持续集成