通常,我们的代码非常模块化,因此开发人员不会同时更改相同的文件。但是,我遇到了一种情况,我认为有两种方法可以解决它,所以我正在寻找关于哪种方法和最佳方法(或其他解决方案)的意见。我的同事对其功能分支中的一些文件进行了更改,我希望在我的功能分支中使用这些文件。这些是单独的功能,而不是共享功能分支。我看到两个解决方案:
1)他可以将他的特征分支合并到开发和推送到原点。然后,我可以拉出开发分支并将我的功能分支重新定位到本地。
2)我可以将他的特征分支直接合并到我的。
我真的不喜欢后者,因为它似乎只是关闭;当两个特征本身不相关时,将特征分支直接合并到特征分支中,只需要几个依赖关系。所以,我选择了前者,但为了将来的参考,我很好奇其他人如何处理这种情况。
答案 0 :(得分:7)
你在git中所做的只是对开发过程的反映。
1)您没有need to rebase您在开发分支上的工作只是将开发分支合并到您的工作分支中。如果你屈服,你就无法分享你的工作。
2)你需要融入他的工作,但他还没有准备好开发,那么你合并他的工作就没有技术问题。只要注意你可能会加入beta工作!
这不是一个git问题,你只是依赖于尚未完成的工作,一直发生,你需要经常合并其他开发人员的工作,直到他完成。
答案 1 :(得分:6)
我理解你更喜欢第一种解决方案的本能,我认为这是正确的方法,因为:
develop
。这很自然:他合并他自己的更改,并在必要时解决他自己的冲突。develop
之上进行重新定位时,您可以有效地合并您自己的更改,并在必要时解决您自己的冲突。同样,这是非常自然和直观的。在另一种选择中,你将他的分支合并到你的分支,也许你必须解决他的冲突。而这实际上只是冰山一角,因为即使合并没有发生冲突,如果构建中断了怎么办?或者如果构建仍然可以,但现在该程序有一些奇怪的行为?另一个人最了解如何处理这些问题。
当原始开发人员合并他们自己的更改时,他们负责保持一切正常:解决冲突,使构建通过,使测试通过,验证更改,从而产生一个可供其他人使用并且功能齐全的软件包。这样,在经过充分验证的分支上工作的下一个开发人员可以安全地假设,如果在他的更改之后某些东西不起作用,原因必须是他自己的更改。
我每天都用这个。我很乐意合并我自己的变化或我的团队的变化,因为我知道它们是什么。我讨厌合并其他团队的变化(如果有的话),因为我不知道它们是什么以及如何测试结果。