注意:如果你已经有了广泛的知识，那么使用下面的一行来快速调整。 解决方案: 假设您在您的工作分支上，并且您是唯一在此工作的人。

git fetch && git rebase origin/master

解决任何冲突，测试你的代码，提交和推送新的变更到远程分支。

                            ~:   For noobs   :~

以下步骤可能会帮助那些刚开始git rebase并想要轻松完成它的人

步骤1:假设此时在YourBranch上没有提交和更改。我们正在拜访你的分公司。

git checkout YourBranch
git pull --rebase

发生了什么事?提取其他开发人员在你的分支上所做的所有更改，并在此基础上重新构建你的更改。

第二步:解决出现的任何冲突。

步骤3:

git checkout master
git pull --rebase

发生了什么事?从远程主服务器获取所有最新更改，并在远程主服务器上重新配置本地主服务器。我总是保持远程主机清洁和释放准备!并且，更喜欢只在本地的主或分支上工作。我建议这样做，直到你掌握了git的更改或提交。 注意:如果您不维护本地主服务器，则不需要此步骤，相反，您可以直接在本地分支上直接执行fetch和rebase远程主服务器。就像我在一开始提到的。

第四步:解决出现的任何冲突。

步骤5:

git checkout YourBranch
git rebase master

发生了什么事?master上的Rebase发生了

第六步:如果有冲突，就要解决。使用git rebase—continue在添加解决的冲突后继续rebase。在任何时候你都可以使用git rebase——abort来中止rebase。

第七步:

git push --force-with-lease 

发生了什么事?将更改推送到远程YourBranch。——force-with-lease将确保在你重基时是否有来自其他开发人员对YourBranch的任何其他传入更改。这比强行推非常有用。如果有任何传入的更改，那么在推送更改之前获取它们来更新您的本地YourBranch。

为什么我需要推动改变?重写提交消息后，在远程YourBranch适当的改变或如果有任何冲突解决?然后，您需要将您在本地回购中解决的更改推到YourBranch的远程回购中

Yahoooo…!您已经成功地完成了调整。

你也可以考虑做以下事情:

git checkout master
git merge YourBranch

什么时候?为什么?如果由您和其他合作开发人员完成更改，则将您的分支合并到主分支。当你以后想在同一个分支上工作时，这使得YourBranch与master保持同步。

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

简单的解决方案:

Git checkout master && Git pull

Git结帐分支

Git rebase master ->解决冲突

转到添加 。

Git rebase—继续

Git push——force-with-lease origin分支

首先从上游存储库中获取新的master，然后在此基础上重新构建你的工作分支:

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

更新:请参阅Paul Draper的回答，以获得更简洁的方法—最近的Git版本提供了一种更简单的方法来执行上述两个命令的等效操作。

1.先更新主…

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

2.现在用主分支重构源分支

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]

然后是...”

步骤1:

git fetch origin

步骤2:

git rebase origin/master

第三步:(修正任何冲突)

git add .

步骤4:

git rebase --continue

步骤5:

git push --force

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

首先,检查 Git的状态，并确保启动在功能分支。

如果不在功能分支中，请尝试git checkout功能 然后

git fetch origin
git rebase -i origin/master

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