典型的单分支git工作流程

Question

我们正在检查git，并希望了解哪个工作流程可能适合我们的小团队（4位开发人员）。

我们所做的一些细节：

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

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

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

例如，今天我们已经看到开发人员的 git push 请求失败，因为之前已经进行过另一次推送，并且他必须使用 git pull 在本地合并更改第一

典型情况是这样的：

开发人员，在本地提交。 从git存储库中提取。 推入git存储库。

难道我们不能跳过拉？ （在远程服务器上完成合并？）

目前我们正在使用ClearCase，这可以通过在推送（“提交”）操作期间合并来解决，而无需先拉取。

Answer 1

首先，我建议至少有两个分支机构。我们称之为master和integration。 Master是目前稳定的生产就绪代码库。无论是在客户手中还是即将提交到App Store（我们都是iOS商店）。集成是我们存储测试就绪代码的地方。如果有人要求测试构建，这就是我们给他们的。这里的代码编译并运行，但并不完美。根据您的部署和测试过程，您可以根据需要添加更多分支。 git中的分支容易且快速，没有理由没有你需要的那么多。

以下是我们的流程的工作原理：

1. 开发人员使用git pull在其计算机上获取最新版本的集成。
2. 从集成创建主题分支。 'git checkout -b fix-home-page`将创建一个名为“fix-home-page”的新分支。
3. 修复修复程序，代码代码每5分钟进行一次新提交，因为git中的提交既简单又快捷。完成功能/错误修复后：
4. 切换回集成分支并使用git pull确保您获得最新的提交。
5. git merge --squash fix-home-page将在一个很好的干净提交中拉入你的分支并保持你的历史线性。
6. git push将您的修补程序推回到主要仓库。

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

最后，回答你的问题：是的，你必须在推动之前做一个git pull。 Git非常适合解决冲突，但如果它无法解决冲突，那么你需要人为干预来弄清楚应该发生什么。

Answer 2

  

难道我们不能跳过拉？ （在远程服务器上完成合并？）

没有。合并可能会导致冲突，而您必须手动解决 - 因此，如果其他开发人员推送自上次更新以来的更改，则必须在推送新更改之前更新本地存储库。

Answer 3

不，git不知道合并会发生什么 - 可能会有冲突 - 并且需要在推送之前将它们合并。

此外，不建议在一个git存储库中安装许多项目，就像在SVN中一样。 Git repos非常轻量级，你可以在不同的回购中拥有单独的项目或一组。这也确保了在一个项目上工作的人不必克隆整个仓库，也不需要“拉”然后推动。