也许

Question

我已经阅读了许多有关git pull --rebase的文章和问题，但是我不确定它如何适用于我的情况-尤其是关于共享/公共分支机构

初始设置：

在master上创建功能分支，将其推送到远程
进行更改，在本地提交
将我的提交推送到远程功能分支

远程母版已更新

我想将对master分支所做的feature合并
git pull --rebase origin master

考虑到我已经提交并推送了它们，--rebase可以做吗？

更新根据Atlassian的说法，一旦分支机构被公开（公开），就不要使用rebase

git rebase的黄金法则是永远不要在公共分支上使用它。

https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing

Answer 1

也许

如果其他人已经签出了您的分支机构（甚至可能做出了自己的本地提交），则重新定级有可能引起合并冲突的噩梦。但是，重新定基通常被认为是项目的良好内务，以保持历史记录的整洁。当您在合并之前重新设置基准时，实际上是在注入快速可转发的提交。如果没有重新设置基准，您将首先合并到您的分支中，然后再回推，如果需要还原您的任何单个提交，则会造成混乱的情况。

无基准

(master) A - - - B - - - C - - - D     E
          \                       \   /
(feature)   F - - - G - - - H - - - I

变基

(master) A - - - B - - - C - - - D                   E
                                  \                 /
(feature)                          F - - - G - - - H

Answer 2

settings.job是安全的操作，因为它仅适用于本地存储库。只有您的本地历史记录会更改。之后，您将无需任何git pull --rebase / force标志就可以进行推送。

从遥控器的角度来看，您所做的更改将是最新的。

force-with-lease将执行合并提交，如果远程上有更改，git pull将重新建立您的本地分支，并在顶部应用您的提交，以保持历史记录平坦。

如果您位于本地和远程都存在的功能分支中，则事情可能会变得复杂。

如果您这样做：

git pull --rebase

那么你也必须

git fetch origin
git checkout feature
git rebase origin/master

表示您也要更改遥控器的历史记录。如果多个人一起工作或依赖于功能分支，则将导致问题。如果您拥有远程分支但没有人触摸它，这是安全的。

功能分支上的`git pull --rebase`合并到原点/主更改中

2 个答案:

也许