如何暂时取消分支？
我从分支 A 启动了一个功能分支 B。然后我对两者都做了一些更改。将 A 合并到 B，然后将 B 合并到 A 会导致两个头都指向相同的合并提交（这正是我想要的，因为 A 中的更改也应该影响分支 B）。现在一段时间内只有A会经历变化。
有没有办法让 B 坚持 A 直到我签出 B 并在那里提交？我当然可以删除 B 并在再次分支时重新创建它，或者在再次分支之前使用 A 并将其合并到 B 中，但这一切都依赖于我记住我的意图......
I started a feature branch B from branch A. Then I made some changes in both. Merging A into B and then B into A results in both heads pointing at the same merged commit (which is what I wanted because changes in A should also affect branch B). Now for a while only A will experience changes.
Is there a way to make B stick to A until I checkout B and make a commit there? I could of course just delete B and recreate it when branching of again, or work with A and merge it into B before branching off again, but that all relies on me remembering my intention...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
不，您不能像您所描述的那样将 B 粘到 A 上。
您已经列出了替代选项。我只是删除B，这样可以确保您记住必须再次分支:)
No, you can't stick B to A like you described it.
You already list the alternative options. I'd just delete B, that makes sure that you remember that you have to branch again :)
我认为 B 的真实姓名足以令人回味，仅在 gitbranch 的输出或 gitk --all 的显示中看到它就足以让您想起这个很酷的新名字您最终想要添加的功能。
下次你对 A 进行更改并想让 B 赶上时，请检查 B 并将其推进到 A 的头部。您写道，A 和 B 目前都指向同一个提交。当您对 A 进行更改后，B 的历史记录仍将包含 A 中未包含的任何内容，因此这是一个简单的变基：
上一个命令检查 B，因此当您准备好继续处理时一个：
I assume B's real name is sufficiently evocative that merely seeing it in the output of
git branchor in the display ofgitk --allis enough to remind you of the cool new feature you eventually want to add.Next time you make changes to A and want to make B catch up, check out B and advance it to A's head. You wrote that A and B currently both point to the same commit. Down the road when you've made changes to A, B's history will still contain nothing that isn't already in A's, so this is an easy rebase:
The previous command checks out B, so when you're ready to continue working on A:
如果您再次将 A 合并到 B，它应该向前跳转到 A，然后您只需再次开始针对 B 进行提交即可。
If you again merge A to B, it should jump forward to meet A, and then you simply start committing against B again.
您可以让 B 成为 A 之上的补丁队列（使用诸如
quilt之类的东西）。然后您就可以在闲暇时对其进行处理；每次你想要更新到 A 的最新版本时，你都会弹出补丁，更新 A，然后再次模糊你的补丁并修复任何损坏的地方。Mercurial 实际上有一个核心扩展，可以轻松地完成此操作并使补丁处于版本控制之下。
我一直这样做，当你正在考虑一堆尚未准备好提交的想法时，它的效果非常好。
这就是您要找的吗？
You could let B be a patch queue (using something like
quilt) on top of A. Then you can work on it at your leisure; each time you want to update to the newest version of A, you pop off your patches, update A, and then fuzz your patches back on again and fix whatever's broken.Mercurial actually has an in-core extension for doing this easily and keeping the patches under revision control.
I do this all the time, and it works out really well when you're toying with a bunch of ideas that aren't ready for commit.
Is that what you're looking for?
假设您有一个包含主代码行的 master 分支。然后您决定实现一个新的 foo 功能，并为此创建一个新分支 foo。然后，您愉快地致力于 foo，开发您的功能，并发现您的 master 分支中存在错误。在这种情况下，通常的 git 工作流程是检查并修复那里的错误。然后，当您继续开发功能时，您可以签出 foo，并使用
git merge master将其更新到您的 master 分支。然后一切都井然有序，无需将任何东西粘在任何地方。（或者，当您稍后将 foo 合并到 master 分支时，您可能会忘记更新 foo 并合并更改。）
Lets say you have a master branch with you main code line. Then you decide to implement a new foo feature, and create a new branch foo for that. Then you happily commit to foo, developing your feature, and find you there's a bug in your master branch. In this case, the usual git workflow is to checkout master a fix the bug there. Then, when you continue to develop your feature, you checkout foo, and bring it up to date with your master branch using
git merge master. Then you have everything in order and there's no need to stick anything anywhere.(Or, you can forget to update foo and merge the changes when you later merge foo to your master branch.)