根据这篇文章，你应该:

创建基于master新版本的新分支 Git分支-b newmaster 将旧的功能分支合并为新的 Git checkout newmaster 解决新特性分支上的冲突

前两个命令可以组合成git checkout -b newmaster。

这样，您的历史记录将保持清晰，因为您不需要反向合并。你不需要这么小心谨慎，因为你不需要做Git的基础。

In Eclipse -

1)结账主分支

Git Repositories ->Click on your repository -> click on Local ->double click master branch
->Click on yes for check out

2)拉主分支

Right click on project ->click on Team -> Click on Pull

3)检查你的功能分支(遵循第一点提到的相同步骤)

4)将master合并为feature

Git Repositories ->Click on your repository -> click on Local ->Right Click on your selected feature branch ->Click on merge ->Click on Local ->Click on Master ->Click on Merge.

5)现在你会在feature branch中看到Master branch的所有变化。消除冲突。

For conflict if any exists ,follow this -
Changes mentioned as Head(<<<<<< HEAD) is your change, Changes mentioned in branch(>>>>>>> branch) is other person change, you can update file accordingly.

注意-您需要为冲突文件添加索引

6)提交并在功能分支中推送你的更改。

Right click on project ->click on Team -> Click on commit -> Commit and Push.

OR

Git Repositories ->Click on your repository -> click on Local ->Right Click on your selected feature branch ->Click on Push Branch ->Preview ->Push

你应该能够在master上重新建立你的分支:

git checkout feature1
git rebase master

处理所有出现的冲突。当你提交bug修复(已经在master中)时，Git会说没有任何更改，可能它们已经被应用了。然后，您将继续使用。(同时跳过已经在master中的提交)

git rebase --skip

如果你在你的特性分支上执行git日志，你会看到bug修复提交只出现一次，而且是在master部分。

要了解更详细的讨论，请参阅关于Git rebase的Git书籍文档(https://git-scm.com/docs/git-rebase)，其中涵盖了这个确切的用例。

================ 编辑额外的上下文 ====================

考虑到@theomega的特殊情况，这个答案是专门针对他提出的问题提供的。注意这部分:

我想防止[…]]提交到我的特性分支上，这与特性实现没有关系。

将他的私有分支重新基于master正是会产生这个结果的原因。相比之下，将master合并到他的分支中将会做他特别不想发生的事情:添加一个与他正通过他的分支进行的特性实现无关的提交。

为了解决阅读问题标题的用户，跳过问题的实际内容和上下文，然后盲目地只阅读顶部的答案，假设它总是适用于他们(不同的)用例，请允许我详细说明:

只重新建立私有分支(即只存在于本地存储库中，没有与他人共享的分支)。重设共享分支将“破坏”其他人可能拥有的副本。 如果你想从一个分支(无论是master还是其他分支)集成到一个公共分支(例如，你已经推动了一个分支打开了一个pull请求，但现在与master有冲突，你需要更新你的分支来解决这些冲突)，你需要合并它们(例如，git合并master，如@Sven的答案)。 如果您愿意的话，还可以将分支合并到本地私有分支中，但是请注意，这会导致在您的分支中提交“外部”。

最后，如果你不满意这个答案不是最适合你的情况，即使它是@theomega，在下面添加评论也不会特别有帮助:我不能控制选择哪个答案，只有@theomega可以。

我们如何将主分支合并到特征分支中?容易:

git checkout feature1
git merge master

在这里强制快速前进合并是没有意义的，因为这是不可能做到的。你同时提交了特性分支和主分支。现在快进是不可能的。

看看GitFlow。这是一个可以遵循的git分支模型，您已经在不知不觉中遵循了。它也是Git的一个扩展，它为新的工作流步骤添加了一些命令，这些命令可以自动执行，否则您需要手动执行。

那么你在工作流程中做对了什么?你有两个分支可以使用，你的feature1分支基本上是GitFlow模型中的“develop”分支。

您从master创建了一个热修复分支，并将其合并回来。现在你被困住了。

GitFlow模型要求您将热修复程序合并到开发分支，在您的示例中是“feature1”。

所以真正的答案是:

git checkout feature1
git merge --no-ff hotfix1

这将把在热修复程序中所做的所有更改添加到功能分支中，但仅限于这些更改。它们可能会与分支中的其他开发变更发生冲突，但是如果您最终将特性分支合并回主分支，则它们不会与主分支发生冲突。

换基时要非常小心。只有当你所做的更改停留在你的存储库的本地时，才会进行基改，例如，你没有将任何分支推到其他存储库。重基是一个很好的工具，可以让你在提交之前把本地提交安排成一个有用的顺序，但是对像你这样的git初学者来说，重基会把事情搞砸。

您可能能够“选择性”地将您需要的提交精确地拉到您的特性分支中。

执行git签出hotfix1以进入hotfix1分支。然后执行git日志以获得所讨论的提交的SHA-1哈希(唯一标识提交的随机字母和数字的大序列)。复制它(或前10个字符左右)。

然后，git签出feature1回到你的功能分支。

然后，git cherry-pick <刚才复制的SHA-1哈希值>

这将把那个提交，而且只有那个提交，拉到你的特性分支中。这个更改将在分支中—您只是“挑选”了它。然后，继续工作，编辑，提交，推送等等。

最终，当你执行另一次从一个分支到你的特性分支的合并时(反之亦然)，Git会识别出你已经在那个特定的提交中合并了，知道它不需要再做一次，然后“跳过”它。

下面是一个脚本，您可以使用它将主分支合并到当前分支中。

该脚本的功能如下:

切换到主分支 拉动主分支 切换回当前分支 将主分支合并到当前分支中

将此代码保存为批处理文件(.bat)，并将脚本放置在存储库中的任何位置。然后点击它运行它，你就设置好了。

:: This batch file pulls current master and merges into current branch

@echo off

:: Option to use the batch file outside the repo and pass the repo path as an arg
set repoPath=%1
cd %repoPath%

FOR /F "tokens=*" %%g IN ('git rev-parse --abbrev-ref HEAD') do (SET currentBranch=%%g)

echo current branch is %currentBranch%
echo switching to master
git checkout master
echo.
echo pulling origin master
git pull origin master
echo.
echo switching back to %currentBranch%
git checkout %currentBranch%
echo.
echo attemting merge master into %currentBranch%
git merge master
echo.
echo script finished successfully
PAUSE