git - 典型的单分支 git 工作流程

Question

我们正在检查 git 并想了解哪种工作流程可能适合我们的小团队(4 位开发人员)。

关于我们所做的一些细节:

• 我们正在开发一种 .NET 产品，该产品目前由 1包含大约 4-5 个解决方案的存储库，总共大约 70 个项目和成长。
• 我们目前有 1 个中央存储库和 1 个分支。
• 每个开发人员都在不同的代码库领域工作，尽管偶尔会协作/修改其他团队成员的代码区域。

对于像我们这样的团队来说，“典型的”git 工作流程是什么？

我希望在“管理”操作上花费尽可能少的时间。

例如，今天我们看到开发人员的 git push 请求失败，因为之前进行了另一次推送，他不得不使用 git pull 在本地 merge 更改首先。

典型的场景是这样的:

开发人员，在本地提交。从 git 存储库中 pull 。推送到 git 存储库。

我们可以不跳过 pull 吗？ (是否已在远程服务器上完成 merge ？)

目前我们正在使用 ClearCase，这可以通过在推送(“提交”)操作期间进行 merge 来解决，而无需先 pull 。

Answer 1

首先，我会推荐至少两个分支。我们称之为 master 和 integration。 Master 是当前稳定的生产就绪代码库。这是客户手中或即将提交给 App Store(我们是 iOS 商店)的内容。集成是我们存储测试就绪代码的地方。如果有人要求测试构建，这就是我们给他们的。此处的代码可以编译和运行，但并不完美。根据您的部署和测试过程，您可以根据需要拥有任意数量的额外分支。 git 中的分支既简单又快速，没有理由不拥有您需要的分支。

我们的流程是这样的:

1. 开发人员使用 git pull 在他们的机器上获取最新版本的集成。
2. 创建集成的主题分支。 'git checkout -b fix-home-page` 将创建一个名为“fix-home-page”的新分支。
3. Fix fix fix，code code code 每 5 分钟进行一次新提交，因为在 git 中提交既简单又快速。完成功能/错误修复后:
4. 切换回集成分支并使用 git pull 确保您获得了最新的提交。
5. git merge --squash fix-home-page 将在一次干净的提交中 pull 入您的分支，并使您的历史保持线性。
6. git push 将您的修复推送回主仓库。

我喜欢 git merge --squash 因为它大大减少了冲突的数量。其他人喜欢使用 rebase，这也会为您提供线性历史记录并保留主题分支中的所有提交。使用适合您的任何东西。

最后，回答你的问题:是的，你必须在推送之前执行 git pull。 Git 非常擅长解决冲突，但如果它不能解决冲突，那么您需要人工干预来弄清楚应该发生什么。