相关疑难解决方法(0)

Git的命令文档rebase非常简短:

--preserve-merges
    Instead of ignoring merges, try to recreate them.

This uses the --interactive machinery internally, but combining it
with the --interactive option explicitly is generally not a good idea
unless you know what you are doing (see BUGS below).

那么当你使用时会发生什么--preserve-merges？它与默认行为(没有该标志)有何不同？"重新创建"合并等意味着什么？

我的git在同一个分支中有两个标签.它们之间至少有5-6个提交.如何在两个标签之间创建一个补丁,以便它可以应用于GitHub存储库？

我有一个分支机构,过去几个月我一直在几台计算机上亲自工作.结果是一个很长的历史链,我想在将它合并到主分支之前进行清理.最终目标是摆脱我在处理服务器代码时经常做的所有wip提交.

以下是gitk历史可视化的屏幕截图:

http://imgur.com/a/I9feO

在这个底部的方式是我从主人分支的点.自从我开始这个分支以来,Master已经改变了一点,但是这些变化是不相交的,所以合并应该是小菜一碟.我通常的工作流程是重新加入master,然后压缩wip提交.

我试着执行一个简单的

git rebase -i master

我编辑了对sqush的提交.

它似乎开始很好,但后来失败了,并希望我解决冲突.然而,似乎没有好办法通过观察差异来解决它.每个部分都使用范围中未定义的变量,因此我不确定如何解决它们.

我也试图使用git rebase -i -s recursive -X theirs master,但没有导致冲突,但是它改变了修改后的分支的HEAD状态(我想以这样的方式编辑历史记录,即HEAD中的最终结果不会改变).

我相信这些冲突来自于你可以看到钻石图案的链条部分.(例如,在重新分类的分类器......和Merge分支iccv之间).

要更好地A说出我的问题,请让" =合并分支iccv"和B="返工分类器"参考图像中的示例.中间的提交将是X和Y.

      ...
       |
       |
       A 
     /  \
    |   X
    Y   |
     \ /
      B
      |
      |
     ...

我想改写历史这样的状态A是完全一样的,并有效地破坏中间表示X和Y,因此产生的历史是这样的

      ...
       |
       |
       A 
       |
       |
       B
       |
       | 
      ...

有没有办法在这样的历史链中间压缩已解决的状态A,X并Y进入单个提交？

如果A并且B是提交的SHAID是否有一个简单的命令我可以运行(或者可能是一个脚本)来实现我想要的结果？

如果A是HEAD,我相信我能做到 …