Git Rebase与“反向合并”

Question

在git中，如果我有一个旧功能，可以称之为它，从feature/improvement主分支分支出来的master大约要提交500次提交，feature/improvement需要更新，我看到3个选项。

1. 将母版合并到功能/改进中
2. 将功能/改进合并到master指向的提交上，并将功能/改进的branchref更改为指向新的合并提交。
3. 变基了吗？

2对我来说似乎是最直接的选择，它显示了合并提交，并显示了旧的更改，并重新应用于最新的主更改。

但是工具和历史非常混乱，因为它是“向后”或“反向”

我是否误解了一些基本知识？有我不明白的明显缺点吗？

为什么要变基？

修改：

根据要求，我创建了一个“反向合并”的演示仓库，对不起的git命令/错字很抱歉。

306  touch demo.txt
  307  echo "1" > demo.txt
  308  git add demo.txt
  309  git commit "Master 1"
  310  git status
  311  git commit -m "Master 1"
  312  echo "2" > demo.txt
  313  git commit "Master 2"
  314  git add .
  315  git commit -m "Master 2"
  316  git status
  317  git log
  318  git branch feature
  319  git checkout feature
  320  echo "a" > demo.txt
  321  echo "b" > demo.txt
  322  echo "c" > demo.txt
  323  git commit -m "feature c"
  324  git add .
  325  git commit -m "feature c"
  326  echo "d" > demo.txt
  327  git commit -m "feature d"
  328  git add .
  329  git commit -m "feature d"
  330  git checkout master
  331  echo "3" > demo.txt
  332  git add .
  333  git commit -m "master 3"
  334  echo "4" > demo.txt
  335  git add .
  336  git commit -m "master 4"
  337  echo "5" > demo.txt
  338  git add .
  339  git commit -m "master 5"
  340  git branch feature2
  341  git checkout feature2
  342  git merge help
  343  git help merge
  344  git merge feature
  345  git add .
  // This is where I gave up, and Used Source Tree to use a GUI to reset feature to feature2's ref
  346  git status
  347  git commit
  348  git status
  349  echo "e" > demo.txt
  350  git add .
  351  git commit -m "feature e"
  352  checkout -b "master"
  353  git checkout master
  354  git commit -m "master 6"
  355  echo "6" > demo.txt
  356  git add .
  357  git commit -m "master 6"

结果

Answer 1

合并将采用master中的所有更改，并尝试将它们与feature/improvement的更改合并。请原谅可怜的ascii图...

master   -------------
feature  \----\--
         ^    ^
    Branch    Merge

重新设置基准将获取feature/improvement中的所有更改，并实际上将它们更改为好像在提交master的更改之后已提交一样。

变基之前：

master   -------------
feature  \------
         ^
    Branch

恢复基准后：

master   -------------
feature               \------
                      ^
                 Branch

换句话说：

• 合并：“合并这两个提交”
• Rebase：“重写历史记录，以便我提交中的所有更改仅在主服务器之后应用”

Answer 2

@Jim Wright的答案很好。关于$ git rebase的一些其他想法：

就生成的源代码而言，合并和重新设置之间有什么区别？

没有。两项操作完成后将产生相同的源代码。

为什么要变基？

Git的变基操作将使您的项目历史更加线性，从而更易于阅读。

不是“重写”提交历史的命令，例如git rebase不好吗？

我认为改基不好。这是保持历史可读性的非常有用的技术。  清晰易读的VCS历史记录有助于理解项目的发展。我建议即使需要一些额外的努力，也要保持整洁。

另一方面，如果您正在使用已发布的主题分支，则应避免执行会重写历史记录的操作，因为这可能会影响撤消该分支的其他团队成员。就是说，一些团队（如我的团队）具有关于在主题分支上重写历史记录的宽松规则。我的团队很小。如果我确信没有其他人拉过 my 分支，那么我可能会很好地调整基础。合并拉取请求时，我还将定期对过时的主题分支进行基准调整。

“重写”提交怎么办？我以为Git的历史是用密码密封的？

Git不会覆盖任何提交。它复制或重播提交以进行诸如变基等操作。实际上，在一段时间内，复制的Git提交仍将通过reflog可用。它们不会通过变基操作自动销毁，可以在必要时恢复。

Answer 3

我不知道反向合并。但是在这种情况下，我们有两种选择。首先，git rebase。让我们看看变基的作用。 考虑以下历史记录： 母版：c1，c2，c3，c4 改进：c1，c2，c5，c6，c7 got checkout improvement git rebase master 现在，首先将删除您在yot分支上所做的所有提交，然后将应用来自master的新提交，使您的历史记录与master相同。在此之后，rebase将把您的工作应用在其顶部。

您的历史记录变为： c1，c2，c3，c4，c5，c6，c7

根据我的说法，这使事情变得非常复杂，但是如果您已经将更改从improvement推送到远程，则不建议进行重新设置基准，因为这可能会导致重复的提交。

第二次，git合并，

它将把您的master分支上的提交与合并提交一起应用到改进分支上。如果您已经远程推送了游览分支，建议使用此选项。

希望有帮助。