我的团队一直敦促我使用 rebase 而不是合并。我不太擅长 GIT。但我一直在使用合并将提交从主分支合并到我的功能分支，然后使用拉取请求/合并请求来压缩并最终提交到主分支。
但现在在我的新团队中，他们是 rebase 的信徒。我是新来的。我所知道的是，将功能分支变基为主分支以获得更清晰的历史记录和内容是很好的。但反过来又如何呢？当我在开发中并且我想要来自 master 的最新更改时，我应该从 master 分支变基或合并到功能分支吗？在这种情况下有什么好处？
您通常希望将功能重新设置为 master，而不是相反。 Git 中的提交是永久且不可变的；它们创建后就永远不能更改。
Rebase 不会更改提交，它会创建看起来像现有提交的新提交。创建所有副本后，通过移动分支，旧的提交将被“遗忘”。 Git 中的分支只不过是指向单个提交的指针。
由于 master 上的提交通常被认为是“已发布的工作”和“共享”，所以你不想忘记它们 - 通常你不能，因为其他人有它们的本地副本：每个人都会必须忘记提交曾经存在过。
您的两个变基场景是什么样的？首先，让我们看一下变基之前的历史记录：
,D-E-F < master
...-A-B-C
`X-Y-Z < feature
为了完整起见，让我们想象一下合并这两个分支的结果会是什么样子。场景 1：“接受功能”。这相当于
git checkout master && git merge feature
,D-E-F-M < master
...-A-B-C /
`X-Y-Z < feature
场景2：“与master同步”。这相当于git checkout feature && git merge master
,D-E-F < master
...-A-B-C \
`X-Y-Z-M < feature
如果您稍后“接受”您的功能，您最终将得到以下历史记录：
,D-E-F---N < master
...-A-B-C \ /
`X-Y-Z-M < feature
现在，回到变基。相同的起始历史：
,D-E-F < master
...-A-B-C
`X-Y-Z < feature
场景1：“与master同步”。这相当于 git rebase master feature
（或
git checkout feature && git rebase master；甚至
git --onto master master feature）
,D-E-F < master
...-A-B-C \
\ `X'-Y'-Z' < feature
\
`X-Y-Z
请注意，提交 X
、
Y和
Z已被“遗忘”，它们不再可以通过任何分支或标签到达。然而，复制的提交（由
'表示）可以通过更新的分支名称访问。分支功能现在包含来自主功能和功能的更改。
此操作完全忽略提交
D
、
E和
F（可通过 master 访问）。场景 2：“不知道该怎么称呼它:)”
git rebase feature master
（或
git checkout master && git rebase feature；或
git rebase --onto feature feature master）
,D-E-F < (origin/master)
/
/ ,D'-E'-F' < master
...-A-B-C /
`X-Y-Z < feature
（公共、共享）提交 D
、
E和
F不再可以通过本地分支访问（但仍然可以通过远程跟踪分支，并且可能通过其他克隆中的本地分支）。但是如果你查看功能分支，它仍然不包含 master 的更改！
TL;DR：变基时，您希望将功能分支变基到 master。您不想重写共享历史记录。