假设我有2个分支：v1.0和development。
我们的过程是使用以下方法创建本地分支：
git merge-base v1.0 development
git checkout <commit-hash>
git checkout -b <new-branch-name>
假设我的一位同事遵循相同的流程并最近通过以下方式进行了更改：
git checkout v1.0
git merge <his-local-branch-name>
git push
git checkout development
git merge <his-local-branch-name>
git push
我的问题是，如何通过最近的更改轻松更新我的本地分支？
我做的是使用merge-base创建另一个带有最近更改的分支，并将其与我在本地进行的更改合并。
但它存在一些简单的方法吗？我在考虑像git merge <last-commit-hash>之类的东西，但它会产生很多冲突。
答案 0 :(得分：1)
好的......所以听起来development是一个代表以前版本的长寿分支 - 很像gitflow中的master。
听起来v1.0是一个长期存在的分支，您正在组装下一个版本，就像gitflow中的develop一样。
一个给定的本地分支可能就像一个功能分支（在这种情况下你将它合并到v1.0）或者像一个修补程序（在这种情况下你将它合并到两个{ {1}}和v1.0）。奇怪的是，您似乎总是创建本地分支，以便可以合并到两者。 （所以你不知道，在分支机构创建时，你是否要合并到development？因为如果不是这样的话，那么让每个分支重新开始＆＃34;在合并基础上似乎有一些不必要的合并解决成本...但我离题了。）
让我们通过图片逐步完成您的方案。你从
开始development并创建一个本地分支
A -- x <--(development)
\
Z <--(v1.0)
并且您的同事创建了一个本地分支
A -- x <--(development)
|\
| Z <--(v1.0)
\
B -- C <--(feature)
（在这里跟我一起;我意识到可能永远不会有任何一个包含所有这些分支的回购，但让我们只看一下＆＃34;大图片＆＃34;无论如何...... ）
所以你的同事合并到两个长寿的分支
A -- x <--(development)
|\
| x -- O <--(hotfix)
|\
| Z <--(v1.0)
\
B -- C <--(feature)
请注意，从现在开始，A -- x -- M <--(development)
|\ /
| x --- O <--(hotfix)
|\ \
| Z ----- M <--(v1.0)
\
B -- C <--(feature)
是O和development的合并基础。但是您的分支是在合并基础为v1.0时创建的，所以现在我们就会问您：如何将A引入您的分支。
到目前为止hotfix是共享历史记录中不可或缺的一部分，因此您可能不想做任何重写和/或重复提交更改的内容。
您可能不希望将hotfix合并到您的分支中，因为将v1.0混合到您的分支中似乎违背了在合并基础上创建分支的细节。< / p>
所以你真的只想将Z组合到你的分支中。现在让我们稍微改变一下，看看你的本地回购可能会看到什么，如果我接受你的术语＆＃34;当地分支机构＆＃34;从字面上看（意思是你没有O分支）：
hotfix现在，鉴于A -- x -- M <--(development)
|\ /
| x --- O
|\ \
| Z ----- M <--(v1.0)
\
B -- C <--(feature)
也是本地（仅存在于您的仓库中），一个选项是将其重新绑定到新的合并库 - 这似乎仍然存在于你工作流的精神。
feature会给你
git rebase $(git merge-base development v1.0) feature
此时A -- x -- M <--(development)
|\ /
| x --- O -- B' -- C' <--(feature)
\ \
Z ----- M <--(v1.0)
和B'都是未经测试的代码状态。理想情况下，您应该测试它们并解决任何问题（但是，如果C'中存在问题说起来容易做起来难以理解），那么您仍然可以获得干净的历史记录。
另一个选项，可以避免＆＃34;未经测试的提交＆＃34;问题，但创造一个＆＃34; messier＆＃34; （虽然可以说更准确）历史，就是简单地将合并基础合并到你的分支中。
B'这给你一些类似的东西
git checkout feature
git merge $(git merge-base v1.0 development)
其中，在花了很长时间来说＆＃34;为什么＆＃34;，意味着我们基本上做了你已经做过的事情，除了跳过为合并创建分支的步骤，因为我们可以只参考合并直接基地。
这是有道理的。您已经知道要与您的分支机构合并的更改内容 - 您实际上并非希望更改您要合并的内容。因此，我们所能做的最好的事情就是找到一种更简单的方式来引用这些变化。
答案 1 :(得分：1)
我所做的是使用merge-base创建具有最新更改的另一个分支，并将其与我在本地所做的更改合并。
那是一种方法（Mark说明了变基方法in his answer）
但不是那样，使用Git 2.22（2019年第二季度），您不必做：
git merge-base v1.0 development
git checkout <commit-hash>
git checkout -b <new-branch-name>
相反，您可以这样做：
git checkout -b <new-branch-name> v1.0...development
请参见commit e3d6539的commit 27434bf，Denton Liu (Denton-L)（2019年4月27日）。
帮助者：Junio C Hamano (gitster)。
（由Junio C Hamano -- gitster --在commit 4ac8371中合并，2019年5月19日）
branch：使create_branch接受合并基础版本当我们运行类似的东西
$ git checkout -b test master...它将失败并显示消息
fatal: Not a valid object name: 'master...'.这是由于调用了
create_branch，其中start_name是 应该是有效的版本。
但是，git checkout允许分支 成为有效的合并基础 rev（即带有“...”），因此有可能 要传递的无效版本。使
create_branch接受合并基础版本，这样就不会出现这种情况 错误。作为副作用，请教git-branch如何处理合并基本版本为 好吧。