如何将本地分支重新定位到远程主控上答案

【问题标题】：How to rebase local branch onto remote master如何将本地分支重新定位到远程主控上
【发布时间】：2011-12-17 06:43:10
【问题描述】：

我从远程存储库remote_repo 的主分支克隆了一个项目。我创建了一个新分支并提交到该分支。其他程序员将remote_repo推送到master分支。

我现在需要将我的本地分支 RB 重新定位到 remote_repo 的 master 分支。

如何做到这一点？向终端键入什么命令？

【问题讨论】：

对我来说，这个问题是模棱两可的，因为“with”可能意味着在任一方向上变基。查看答案，我发现其目的是将您的分支重新设置为到远程主机，而不是相反。我会提到它，以防有人遵循下面的答案并得到他们想要的相反。
@GlennLawrence 我认为编辑原始问题比添加评论更好。 stackoverflow 也鼓励这样做。此外，将 master 重新定位到 RB 上可能无论如何都会失败，因为 RB 依赖于 master 的历史。

标签： git clone git-rebase

【解决方案1】：

首先从上游存储库中获取新的 master，然后在此基础上重新设置您的工作分支：

git fetch origin            # Updates origin/master
git rebase origin/master    # Rebases current branch onto origin/master

更新：请参阅Paul Draper's answer 了解更简洁的方法 - 最近的 Git 版本提供了一种更简单的方法来执行上述两个命令的等效操作。

【讨论】：

这是唯一真正符合要求的答案
@kayaker243 不，这与 Paul Drapers 的回答相同，但我认为格式很长。
@erik 请注意，Paul Draper 在 kayaker243 发表评论后大约半年写了他的答案（并且在这个答案之后将近两年）。
我得到以下信息：Your branch and 'origin/b1' have diverged, # and have 3 and 2 different commits each, respectively. 似乎需要另一个 git pull。这是正确的还是我在这里遗漏了什么？
@RGC 不，git rebase master 不会做与第二个命令 (git rebase origin/master) 相同的工作，因为 master 和 origin/master 很可能指向不同的提交（特别是考虑到第一个命令是git fetch origin，可能会修改origin/master）。

【解决方案2】：

git pull --rebase origin master

【讨论】：

（相当于 Frerich 的回答）
这与 Frerich 的回答是否略有不同，因为这会将更改从原始主机提交到本地主机，而 Frerich 的回答不会影响本地主机？（拉取与获取）
不，在 Frerich 的回答中，rebase 修改了本地 master。 pull --rebase 与 fetch 后跟 rebase 是一样的
仅供参考，您可以使用 git pull --rebase=interactive origin master 进行交互式变基
@adhominem - 我检查了git-pull documentation，我看不到任何支持本地主机被修改的说法。如果我在名为dev 的分支上运行git pull --rebase origin master，则只会修改分支dev，而不是master。 --rebase 标志文档声明它尝试 rebase the current branch on top of the upstream branch after fetching 并且没有修改本地跟踪分支。

【解决方案3】：

在提交更改到您的分支后，签出 master 并将其拉取以从 repo 中获取其最新更改：

git checkout master
git pull origin master

然后检查您的分支并将您的更改基于master：

git checkout RB
git rebase master

...或一行中的最后两个命令：

git rebase master RB

当你试图推回origin/RB 时，你可能会得到一个错误；如果你是唯一一个在 RB 工作的人，你可以强制推送：

git push --force origin RB

...如果你已经正确配置了 git，如下所示：

git push -f

【讨论】：

当你试图推回原点/RB时，你可能会得到一个错误。如果你是唯一一个在 RB 上工作的人，你可以 git push --force origin RB。来源：stackoverflow.com/questions/8939977/…
啊....我有这个。我的“RB”已正确重新设置基准，但在重新设置基准后尝试推送它时出现无穷无尽的错误。除了 push --force origin RB - 还有“更好”（非强制）的方法吗？我只是试图在这里理解 gits 的看法——但失败了。
@MottiShneor 不，没有好办法。如果其他人同时推送到分支，他们的更改将丢失！如果您想对 git 提交历史记录友好，您应该将 master 合并到您的分支中，这是安全的（您可以在没有 -f 的情况下执行 git push）。
感谢您的回答。这对我帮助很大。很多。
git push --force-with-lease 是在变基后推送更改的更安全的方式。它基本上会在推送您的更改之前检查您团队的其他成员是否已提交。见stackoverflow.com/questions/52823692/…

【解决方案4】：

注意：如果您已经对 rebase 有广泛的了解，那么使用下面的一个衬垫来快速 rebase。 解决方案： 假设你在你的工作分支上，并且你是唯一一个在工作的人。

git fetch && git rebase origin/master

解决任何冲突、测试您的代码、提交新的更改并将其推送到远程分支。

                            ~:   For noobs   :~

以下步骤可能会对 git rebase 的新手有所帮助并希望轻松完成此操作

步骤 1： 假设此时 YourBranch 上没有提交和更改。我们正在访问 YourBranch。

git checkout YourBranch
git pull --rebase

发生了什么？提取其他开发人员在您的分支上所做的所有更改，并在此基础上重新调整您的更改。

第 2 步：解决出现的任何冲突。

第 3 步：

git checkout master
git pull --rebase

发生了什么？ 从远程 master 中提取所有最新更改并将本地 master 重新定位到远程 master 上。我始终保持远程主机清洁并准备好发布！而且，更喜欢只在本地的 master 或分支上工作。我建议这样做，直到您掌握 git 更改或提交。注意：如果您不维护本地 master，则不需要此步骤，而是可以直接在本地分支上直接执行 fetch 和 rebase 远程 master。正如我在开始的单步中提到的那样。

第 4 步：解决出现的任何冲突。

第 5 步：

git checkout YourBranch
git rebase master

发生了什么事？主控发生了变基

第 6 步：解决任何冲突（如果存在冲突）。添加已解决的冲突后，使用git rebase --continue 继续变基。您可以随时使用git rebase --abort 中止变基。

第 7 步：

git push --force-with-lease

发生了什么？将更改推送到远程 YourBranch。 --force-with-lease 将确保在您变基时是否有来自其他开发人员的 YourBranch 的任何其他传入更改。这是超级有用的，而不是强制推动。如果有任何传入的更改，则在推送更改之前获取它们以更新您的本地 YourBranch。

为什么我需要推送更改？ 正确变基后重写远程 YourBranch 中的提交消息或如果解决了任何冲突？然后你需要将你在本地 repo 中解决的更改推送到 YourBranch 的远程 repo

雅虎……！您已成功完成变基。

您可能也在考虑这样做：

git checkout master
git merge YourBranch

何时以及为什么？如果您和其他合作开发者进行了更改，请将您的分支合并到 master 中。当您以后想在同一分支上工作时，这会使 YourBranch 与 master 保持同步。

                            ~:   (๑ơ ₃ ơ)♥ rebase   :~

【讨论】：

这是为了什么：“从 master 中提取所有最新的更改，并将 master 重新设置在最新的 master 上。”。在主控上重新设置主控？不是只需要拉最新的master吗？
@JohnLittle 感谢您的指出。我的意思是Pulls latest changes from remote master to local master. I always prefer keeping remote master clean and release ready always!。我会更新我的描述。
git push --force-with-lease 是一个棘手的问题，在变基时没人会谈论它，因为你会得到一个 your branch is X ahead and Y behind origin，如果你再次尝试拉和推，就会把事情弄得一团糟。

【解决方案5】：

第 1 步：

git fetch origin

第 2 步：

git rebase origin/master

第 3 步：（如果有冲突，请修复）

git add .

第 4 步：

git rebase --continue

第 5 步：

git push --force

【讨论】：

没有解释从哪个分支开始。不是一个好的答案。
如果您不知道确切的含义，请不要这样做。强制推送不是一个好主意。
！！！请不要这样做git push --force 可能非常非常危险。 datree.io/resources/git-push-force
大多数答案，包括评分最高的答案都是强制推动。如果您不强制推送，您将不会将历史记录正确排列在 master 或您要重新建立的任何分支上。
应该是git fetch origin master

【解决方案6】：

1.先更新Master...

git checkout [master branch]
git pull [master branch]

2.现在用 master 分支 rebase source-branch

git checkout [source branch]
git rebase [master branch]
git pull [source branch] (remote/source branch)
git push [source branch]

如果远程上尚不存在源分支，则执行以下操作：

git push -u origin [source branch]

“等等……”

【讨论】：

我喜欢这个答案的逐步说明。它有助于分解到底发生了什么。

【解决方案7】：

git fetch origin master:master 拉取最新版本的master，无需查看。

所以你只需要：

git fetch origin master:master && git rebase master?

【讨论】：

git fetch 不更新 master 而不需要检查它吗？除了git fetch 不是git merge 更新对吗？所以如果我们结帐master 它不会有最新的更新。那么在功能分支上做git fetch然后git rebase origin/master不是更短吗？我们不能做git rebase master，因为那会尝试从工作空间中的master 变基，我们需要origin/master 从未合并但位于本地的位置获取。

【解决方案8】：

如果当前分支有很多提交，并且需要在变基之前对其进行压缩、修复和重写，那么交互式变基是正确的答案。当软件工程师说“在 master 之上 rebase”时，他们通常的意思是“在 origin/master 之上进行交互式 rebase，并确保它看起来很棒，并且压缩了不必要的提交，并更正了提交消息”。

首先，检查 git status 并确保从功能分支开始。

如果不在功能分支中，请尝试git checkout feature 那么

git fetch origin
git rebase -i origin/master

很少情况下，提交历史记录已准备好重新设置基准，就像请求在 master 之上重新设置基准一样。在大多数情况下，现有提交首先使用交互式 rebase 进行修改。

【讨论】：