Git - 在开发人员之间将一个功能分支的更改合并到另一个功能分支

Question

通常,我们的代码非常模块化,因此开发人员不会同时更改相同的文件.但是,我遇到了一种情况,我看到有两种方法可以解决它,所以我正在寻找关于哪种方式和最佳方式(或其他解决方案)的意见.我的同事对其功能分支中的一些文件进行了更改,我希望在我的功能分支中使用这些文件.这些是单独的功能,而不是共享功能分支.我看到两个解决方案:

1)他可以将他的特征分支合并到开发和推送到原点.然后我可以拉开开发分支并将我的功能分支重新定位到本地.

2)我可以将他的特征分支直接合并到我的.

我真的不喜欢后者,因为它似乎只是关闭; 当两个特征本身不相关时,将特征分支直接合并到特征分支中,只需要几个依赖关系.所以,我选择了前者,但为了将来的参考,我很好奇其他人如何处理这种情况.

Answer 1

你在git中所做的只是对开发过程的反映.

1)您不需要在开发分支上重新定义您的工作,只需将开发分支合并到您的工作分支中即可.如果你改变,你就无法分享你的工作.

2)你需要整合他的工作,但他还没有准备好开发,那么你合并他的工作就没有技术问题.只要注意你可能会加入beta工作!

这不是一个git问题,你只是依赖于尚未完成的工作,一直发生,你需要经常合并其他开发人员的工作,直到他完成.

Answer 2

我理解你更喜欢第一种解决方案的本能,我认为这是正确的方法,因为:

• 另一个开发人员将他自己的更改合并到develop.这很自然:他融合了自己的变化,必要时解决了自己的冲突.
• 当您在最重要的基础上进行重新定义时develop,您可以有效地合并您自己的更改,并在必要时解决您自己的冲突.同样,这是非常自然和直观的.

在另一种选择中,你将他的分支合并到你的分支,也许你将不得不解决他的冲突.这实际上只是冰山一角,因为即使合并没有发生冲突,如果构建中断了怎么办？或者如果构建仍然可以,但现在该程序有一些奇怪的行为？另一个人最了解如何处理这些问题.

当原始开发人员合并他们自己的更改时,他们负责保持一切正常:解决冲突,使构建通过,使测试通过,验证更改,从而产生一个可供其他人使用并且功能齐全的软件包.这样,在经过充分验证的分支上工作的下一个开发人员可以安全地假设如果在他的更改之后某些东西不起作用,原因必须是他自己的更改.

我每天都用这个.我很乐意合并我自己的变化或我的团队的变化,因为我知道它们是什么.我讨厌合并其他团队的变化(如果有的话),因为我不知道它们是什么以及如何测试结果.