对于我使用的其他源代码控制系统,总有一种方法可以确保如果构建工作所需的某些全局更改或运行它的单元测试将立即供所有开发人员使用。但是使用git,如果每个开发人员都在自己的存储库中的一个单独的分支上工作,那么如何实现这一目标并不清楚。例如,就在昨天,我不得不对单元测试进行更改,现在它已经不再是2016年了,但每个推动提交到他们自己的分支机构的开发人员都会因为他们没有拉动而导致ci构建失败。从主分支与修复程序合并。我们还经常因为构建服务器和网络配置的变化而改变构建脚本,但同样,似乎没有明显的方法来自动地推送#34;这些更改将对所有开发人员进对于这类问题,有没有好的/已知的解决方案?当然不仅仅是我们......
答案 0 :(得分:1)
正如您所提到的那样,您的构建脚本总是会更改,但是执行版本控制并不会影响git。
您的远程存储库的URL是稳定的,足以支持git。
为了确保开发人员基于最新的主分支工作,有两种方法:
git fetch origin master
git diff master..origin/master
如果有输出,则表示本地主分支不是最新的。您应该通过branchX
和git git checkout branchX
在最新主分支的顶部重新定位您的本地pull origin master --rebase
。
BTW ,您团队的分支模块是什么。开发人员在他们自己的开发分支上开发工作,然后将他们的工作推送到远程开发分支。但是谁会将dev分支的变化合并到master分支?如果您只有开发团队(没有QA或某些),常见的方法是每个开发人员都应将其更改合并到master分支,然后将本地master分支推送到远程。因此,如果本地主分支不是最新的,git将停止推送并提示您的原因。如果这是你的情况,我认为这是更好的方法。
如果你有更多团队。如开发,质量保证等,您可以a successful git branch module参考。
<强>更新强>
无论CI构建还是测试,所有这些步骤都将在开发人员将其本地更改推送到远程存储库后执行。 所以开发的常规方法是将其本地更改合并到master分支,然后将master分支推送到远程。如果开发人员本地master分支不是最新的,git会自动停止用户推送和提示拉首先从远程改变。
答案 1 :(得分:0)
我不是git专家,但对于那种情况,我认为在开发人员进行更改之前没有自动选项。这将更新他们的开发分支,他们必须将更改合并到他们自己的分支。他们有两种选择,将开发集成到他们的分支或者挑选包含所需更改的特定提交。
答案 2 :(得分:0)
正如你所说,有些时候你的主人没有通过测试,有些时候没有。所以解决方案很简单 - 让开发人员从已经通过所有测试的提交开始他们的分支。
PS:我曾经读过Linus关于Linux内核开发的一些咆哮 - 他要求开发人员将他们的补丁基于已发布的内核版本,而不是随机的主提交,这恰好是当前的。我认为这条规则有一点意义。PS2:如果您的测试结果取决于当前日期,或者有其他原因导致相同的源代码失败,即使在错误之前已经过了,您应该付出一些努力以使其不会发生