git：合并方向之间的差异答案

【问题标题】：git: difference between direction of mergegit：合并方向之间的差异
【发布时间】：2021-02-18 22:11:25
【问题描述】：

我使用 git 已经有一段时间了，但我的合并一直很简单。创建一个分支，将其合并到 master。有时 2 个人的分支会涉及相同的代码，因此会出现合并冲突，通常很容易修复。

但现在我有一个案例，其中创建了一个分支并进行了许多重大更改。同时对master进行了很多更改，并且两者都更改了相同的文件。我们希望合并两个分支的所有更改。我们完全预计会有冲突，但我们希望将它们保持在最低限度。

我的问题是，将 master 合并到分支、解决冲突、然后将其合并到 master 与将分支合并到 master 并解决那里的冲突之间有什么区别吗？

是否有任何提示或最佳实践可以进行这样的复杂合并以避免丢失任何更改？

【问题讨论】：

不是真的.... 对 git 来说是一回事。如果你以任何一种方式合并，冲突将是相同的，不同之处在于在冲突块中，来自 2 个分支的 2 个部分的顺序是倒置的（注意我没有说任何关于共同祖先的事情......那是故意，如果您使用 diff3 作为合并冲突样式...如果您使用它，该部分将保留在中间）。您应该留在基础分支并合并功能分支，这样当您执行git checkout main~2 之类的操作时，它不会进入功能分支，而是遵循主分支修订。
查看git imerge 了解缓慢而谨慎的方法。您的两个备选方案将使用不同的“我们的”和“他们的”标签显示相同的冲突。
谢谢 - imerge 看起来很有用。

标签： git merge

【解决方案1】：

您不应将master 合并到主题分支。
最佳实践是将特定分支（如主题/功能分支）合并到集成分支（如“development”或“master”）

在您的情况下，git rebase 更好，可以在本地解决您的分支和 master 之间的任何冲突。
然后，从您的分支合并到 master 将是微不足道的，因为所有提交都将在 master 之上重新创建：

cd /path/to/local/repo
git fetch
git switch myBranch
git rebase origin/master
# resolve conflict
git push --force

git switch -C master origin/master
git merge myBranch
git push

【讨论】：

合并和变基有什么区别？
@NormanRobins 参见medium.datadriveninvestor.com/…：目标是在推送之前重放 myBranch 在更新的origin/master 之上提交。
我们最终进行了变基，这有点像一场噩梦。我们有分支 A.2，我们将 master 重新定位到该分支，然后将重新定位的 A.2 合并到 master 并推送它。我们没有推送重新定位的 A.2，因为我们希望它没有主人的变化。然后在 A.2 和 master 上继续开发，几天后我们再次重新定位。这发现了我们在第一次变基中修复的冲突，以及在两个变基之间的任何一个分支中都没有更改的文件中的大量新冲突。这一切都非常出乎意料。我们通过两次变基做错了吗？
@NormanRobins Rebase master 到那个？您只能在 master 之上重新设置分支，而不是相反。这样，您的分支就在主更改之上完成。
我们这样做了：git checkout A.2。 git rebase 大师。 git结帐大师。 git 合并 A.2。 git推送