典型的单分支git工作流程

lys*_*cid 3 git

我们正在检查git,并希望了解哪个工作流程可能适合我们的小团队(4个开发人员).

关于我们做什么的一些细节:

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

什么是像我们这样的团队的"典型"git工作流程?

我希望尽可能在"管理"操作上花费尽可能少的时间.

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

典型情况是这样的:

开发人员,本地提交.从git存储库中提取.推入git存储库.

我们可以不跳过拉?(在远程服务器上完成合并?)

Currentlly我们正在使用ClearCase,这可以通过在push("commit")操作期间合并而无需先拉取来解决.

kub*_*ubi 11

首先,我建议至少有两个分支机构.我们把我们masterintegration.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非常适合解决冲突,但如果它无法解决冲突,那么你需要人为干预来弄清楚应该发生什么.