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