git - 在合并时跳过特定的提交

问题描述

我一直在使用Git大约一年，并认为它非常棒，但我刚刚开始了第二个版本的项目，并开始为它创建一个新的分支。我正在努力处理未来事情的最佳方式。

我有两个分支，分别称为master10（for v1）和master20（for v2）。我一直在分支master10上对v1进行bug修复，并开发master20的新功能。每当我做一个错误修复时，我通过检查master20并执行 git merge master10 来将它合并到v2中。到目前为止这样好。

现在，我已经在v2中对v1进行了修改，但我想继续合并其他bug修复。我如何让Git跳过那个特定的提交（或一系列提交），但是我仍然希望合并其他错误修复。

我以为 git rebase 可能是我需要的，但阅读文档并且我的头几乎爆炸了。

我想我想要的是就像一个git sync命令，告诉git两个分支现在处于同步状态，将来只会合并来自此同步点的提交。

任何帮助表示赞赏。

解决方案

例如，如果要合并大部分但不是全部的分支maint上的提交到master ， 你可以这样做。它需要一些工作----如上所述，通常的用例是合并来自分支的所有内容---但有时候会发生，你对发布版本进行了更改，而这些发布版本不应该被整合回来（也许该代码的已经被主人取代了），那么你如何表现呢？这里是...

因此，假设maint已经应用了5次更改，其中一个（maint〜3）不会被合并回到master，尽管所有其他人应该是。你需要分三步进行：实际上将所有内容合并到一个之前，告诉git将maint〜3标记为合并，即使不合并，然后合并其余部分。神奇的是：

  bash< master> $ git merge maint〜4 
 bash< master> $ git merge -s our maint〜3 
 bash< master> $ git merge maint 
  

第一个命令将之前的所有内容合并到你的麻烦提示上。默认的合并日志消息将解释你正在合并branchmaint'（early part）。

第二个命令合并麻烦的maint〜3 commit，但是-s我们的选项告诉git使用一种特殊的合并策略，实际上，它通过简单地保持你合并的树来工作，而忽略你完全合并的提交。但它仍然以HEAD和maint〜3作为父项进行新的合并提交，因此修订图现在说明maint〜3被合并。所以实际上你可能也想使用-m选项来'git merge'，以解释那个maint〜3 commit实际上被忽略了！

最后命令简单地将maint（maint〜2..maint）的剩余部分合并到master中，以便您再次同步。

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.

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.

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.

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

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.

Any help appreciated.

解决方案

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...

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

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)".

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!

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

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