假设我们在 Git 中有以下情况：
-
创建的存储库：
mkdir GitTest2
cd GitTest2
git init
-
master 中发生一些修改并提交：
echo "On Master" > file
git commit -a -m "Initial commit"
-
Feature1 从 master 分支出来并完成了一些工作：
git branch feature1
git checkout feature1
echo "Feature1" > featureFile
git commit -a -m "Commit for feature1"
-
同时，在主代码中发现了一个错误，并建立了一个修补分支：
git checkout master
git branch hotfix1
git checkout hotfix1
-
该错误已在修补程序分支中修复并合并回主分支（可能在拉取请求/代码审查之后）：
echo "Bugfix" > bugfixFile
git commit -a -m "Bugfix Commit"
git checkout master
git merge --no-ff hotfix1
-
feature1 的开发仍在继续：
git checkout feature1
假设我需要在我的功能分支中进行修补程序，也许是因为该错误也发生在那里。如何在不将提交复制到功能分支的情况下实现这一目标？
我想防止在我的功能分支上获得两个与功能实现无关的新提交。如果我使用拉取请求，这对我来说尤其重要：所有这些提交也将包含在拉取请求中，并且必须进行审查，尽管这已经完成了（因为修补程序已经在主版本中）。
我不能做git merge master --ff-only：“致命：无法快进，中止。”，但我不确定这是否对我有帮助。
我们如何将master分支合并到feature分支？简单的：
git checkout feature1
git merge master
在这里强制进行快进合并是没有意义的，因为它无法完成。您已将两者提交到功能分支和主分支中。现在快进是不可能的。
看一下GitFlow。它是一个可以遵循的 git 分支模型，而你在不知不觉中已经这样做了。它也是 Git 的扩展，它为新的工作流程步骤添加了一些命令，这些命令可以自动执行您原本需要手动执行的操作。
那么您在工作流程中做了哪些正确的事情呢？您有两个分支可供使用，您的 feature1 分支基本上是 GitFlow 模型中的“开发”分支。
您从 master 创建了一个修补程序分支并将其合并回来。现在你被困住了。
GitFlow 模型要求您将修补程序也合并到开发分支，在您的例子中是“feature1”。
所以真正的答案是：
git checkout feature1
git merge --no-ff hotfix1
这会将修补程序内所做的所有更改添加到功能分支，但是only那些变化。它们可能与分支中的其他开发更改冲突，但如果您最终将功能分支合并回主分支，它们不会与主分支冲突。
变基时要非常小心。仅当您所做的更改保留在存储库本地时才进行变基，例如您没有将任何分支推送到其他存储库。 Rebasing 是一个很好的工具，可以让你在将本地提交推向世界之前将其排列成有用的顺序，但是之后的 rebasing 会让像你这样的 git 初学者搞砸事情。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
