git - 合并时跳过特定的提交 [英] git - skipping specific commits when merging

问题描述

我已经使用 Git 大约一年了，我认为它很棒，但我刚刚开始了该项目的第二个版本，并为其创建了一个新分支.我正在努力寻找处理未来事情的最佳方式.

I've been using Git for about a year now and think it's fantastic, but I've just started on a second version of the project and started a new branch for it. I'm struggling a little with the best way to handle things going forward.

我有两个分支，分别称为 master10(对于 v1)和 master20(对于 v2).我一直在分支 master10 上的 v1 中修复错误，并开发 master20 的新东西.每当我修复错误时，我都会通过检查 master20 并执行 git merge master10 将其合并到 v2 中.到目前为止一切顺利.

I have two branches called say master10 (for v1) and master20 (for v2). I've been making bug fixes in v1 on branch master10, and developing new stuff of master20. Whenever I make a bug fix I merge it into v2 by checking out master20 and doing git merge master10. So far so good.

然而，现在我在 v1 中做了一些我不想在 v2 中进行的更改，但我想继续合并其他错误修复.我如何告诉 Git 跳过该特定提交(或一系列提交)，但在此之后我仍然想合并其他错误修复.

Now however, I've made a change in v1 that I don't want in v2, but I want to continue merging other bug fixes. How do I tell Git to skip that particular commit (or a range of commits), but that going forward I still want to merge other bug fixes.

我认为 git rebase 可能是我所需要的，但阅读文档后我的头几乎要爆炸了.

I thought git rebase might be what I need but read the doc and my head nearly exploded.

我认为我想要的是类似于git sync"命令的东西，它告诉 git 两个分支现在是同步的，并且将来只合并来自这个同步点的提交.

I think what I want is something like a "git sync" command that tells git that two branches are now in-sync and in future only merge the commits from this sync-point on.

感谢任何帮助.

推荐答案

如果您想合并分支maint"上的大部分但不是全部提交以掌握"为例，您可以这样做.它需要一些工作----如上所述，通常的用例是合并分支中的所有内容---但有时会发生您对不应集成回来的发布版本进行了更改(也许该代码的已经在 master 中被取代)，那么你如何表示呢?来了……

If you want to merge most but not all of the commits on branch "maint" to "master", for instance, you can do this. It requires some work---- as mentioned above, the usual use case is to merge everything from a branch--- but sometimes it happens that you made a change to a release version that shouldn't be integrated back (maybe that code's been superceded in master already), so how do you represent that? Here goes...

所以让我们假设 maint 应用了 5 个更改，其中一个 (maint~3) 不会合并回 master，尽管所有其他更改都应该合并.您分三个阶段执行此操作:实际合并之前的所有内容，告诉 git 将 maint~3 标记为已合并，即使它未合并，然后合并其余部分.神奇之处在于:

So let's suppose maint has had 5 changes applied, and one of those (maint~3) is not to be merged back into master, although all the others should be. You do this in three stages: actually merge everything before that one, tell git to mark maint~3 as merged even when it isn't, and then merge the rest. The magic is:

bash <master>$ git merge maint~4
bash <master>$ git merge -s ours maint~3
bash <master>$ git merge maint

第一个命令将您麻烦的维护提交之前的所有内容合并到 master 上.默认合并日志消息将解释您正在合并分支‘维护’(早期部分)".

The first command merges everything before your troublesome maint commit onto master. The default merge log message will explain you're merging "branch 'maint' (early part)".

第二个命令合并了麻烦的 maint~3 提交，但是-s ours"option 告诉 git 使用特殊的合并策略"；事实上，它的工作原理是简单地保留您正在合并的树并忽略您正在完全合并的提交.但它仍然以 HEAD 和 maint~3 作为父项进行新的合并提交，因此修订图现在表示 maint~3 已合并.因此，实际上您可能还想对 git merge 使用 -m 选项，以说明 maint~3 提交实际上被忽略了！

The second command merges the troublesome maint~3 commit, but the "-s ours" option tells git to use a special "merge strategy" which, in fact, works by simply keeping the tree you are merging into and ignoring the commit(s) you are merging completely. But it does still make a new merge commit with HEAD and maint~3 as the parents, so the revision graph now says that maint~3 is merged. So in fact you probably want to use the -m option to git merge as well, to explain that that maint~3 commit is actually being ignored!

最后的命令只是将 maint (maint~2..maint) 的其余部分合并到 master 中，以便您再次同步.

The final command simply merges the rest of maint (maint~2..maint) into master so that you're all synced up again.

这篇关于git - 合并时跳过特定的提交的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！