我从master创建了feature_A分支，然后我必须创建另一个feature_B，它依赖于feature_A（尚未合并到master中）。现在我将feature_A合并到master中，并在feature_B上进一步工作。最后，我准备将feature_B也合并到master中。当尝试合并更改时，我遇到了很多合并冲突。我想知道避免冲突并保持良好的git/PR更改历史的最佳过程是什么？
feature_A
feature_B
master
ax6ht2ek1#
我打赌你在合并feature-A时做了挤压合并，难怪。摆脱混乱的最简单方法是在master之上重定feature-B-only提交的基：
feature-A
feature-B
git rebase last-commit-of-feature-A-as-in-feature-B feature-B --onto master
这应该可以了....现在，* 为什么 * 你陷入这种混乱是因为你挤压合并了feature-A....这并不像是被禁止的，只是要注意git * 不 * 记录任何关于feature-A被合并到master的原始提交的信息，所以，现在你想合并来自feature-B的东西，git看到你可能有来自两个不同分支的不同更改：您在feature-A中开发的代码在feature-B中 * 修改 *，并且代码已经从feature-A合并...因此：冲突顺便说一句，如果你真的合并了 *（而不是squash），它就不会发生。这并不是说你不应该squash（squash是可以的......只要它不是长寿的分支......因为你遇到了 * 这个 * 确切的问题），只是你必须小心它的含义。
1条答案
按热度按时间ax6ht2ek1#
我打赌你在合并
feature-A时做了挤压合并，难怪。摆脱混乱的最简单方法是在master之上重定feature-B-only提交的基：这应该可以了....现在，* 为什么 * 你陷入这种混乱是因为你挤压合并了
feature-A....这并不像是被禁止的，只是要注意git * 不 * 记录任何关于feature-A被合并到master的原始提交的信息，所以，现在你想合并来自feature-B的东西，git看到你可能有来自两个不同分支的不同更改：您在feature-A中开发的代码在feature-B中 * 修改 *，并且代码已经从feature-A合并...因此：冲突顺便说一句，如果你真的合并了 *（而不是squash），它就不会发生。这并不是说你不应该squash（squash是可以的......只要它不是长寿的分支......因为你遇到了 * 这个 * 确切的问题），只是你必须小心它的含义。