Fatal编程技术网
  • git/
  • Git：挤压不是最新提交且不从根开始的连续提交

Git：挤压不是最新提交且不从根开始的连续提交

git version-control

Git：挤压不是最新提交且不从根开始的连续提交,git,version-control,jgit,squash,Git,Version Control,Jgit,Squash,我已经回顾了关于和的几个相关问题，但这两个问题都不能帮助我消除不是根本原因的非最近的提交 以下是我的开始场景： D---E---F---G---H---I---J master 我想要的结果是： D---E---Z---I---J master 其中，Z是对F--G--H的挤压，F--G--H，D--E和I--J可以是任意长的非分支提交序列 第一种方法： [lucas]/home/blah/$ git rebase -i D rebase in progress; onto D You ar

我已经回顾了关于和的几个相关问题，但这两个问题都不能帮助我消除不是根本原因的非最近的提交

以下是我的开始场景：

D---E---F---G---H---I---J master
我想要的结果是：

D---E---Z---I---J master
其中，
Z
是对
F--G--H
的挤压，
F--G--H
，
D--E
和
I--J
可以是任意长的非分支提交序列

第一种方法：

[lucas]/home/blah/$ git rebase -i D
rebase in progress; onto D
You are currently editing a commit while rebasing branch 'master' on 'D'.

No changes
You asked to amend the most recent commit, but doing so would make
it empty. You can repeat your command with --allow-empty, or you can
remove the commit entirely with "git reset HEAD^".

Could not apply F... "Comments from commit F"

[1]+  Done                    gitk
[lucas]/home/blah/$
在这里，我选择commits
F--G--H
作为
squash
，而将最早的提交（rebase interactive中的第一行）保留为
pick
。为什么这样不行

更新：在命令结束时，
D
上正在进行重基，其中
E
是头提交。可以肯定的是，在开始时没有正在进行的rebase，再次运行时调用
git rebase--abort
会得到相同的结果。根据上面的链接，当我在根部或头部执行此操作时，一切正常

第二种方法：

[lucas]/home/blah/$ git rebase -i D
rebase in progress; onto D
You are currently editing a commit while rebasing branch 'master' on 'D'.

No changes
You asked to amend the most recent commit, but doing so would make
it empty. You can repeat your command with --allow-empty, or you can
remove the commit entirely with "git reset HEAD^".

Could not apply F... "Comments from commit F"

[1]+  Done                    gitk
[lucas]/home/blah/$
我做了另一次尝试[通过合并一个新分支（论坛上的最后一篇帖子）][]，它使用了
git checkout-b和
git merge-squash`，但我得到了以下结果：


[lucas-ThinkPad-W520]/home/.../.Solstice_WS/7K_FGHF$ git checkout -b clean-branch D
Switched to branch 'clean-branch'
[lucas-ThinkPad-W520]/home/.../.Solstice_WS/7K_FGHF$ git merge --squash I
Updating D..I
Fast-forward
Squash commit -- not updating HEAD
 .../GraphUtilities/impl/DAG.java              | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)
[lucas]/home/blah/$ git checkout master
error: Your local changes to the following files would be overwritten by checkout:
        asdf/GraphUtilities//DAG.java
Please, commit your changes or stash them before you can switch branches.
Aborting


似乎有这样的结果：


  -------------------  <clean-branch> with non-committed changes
 / 
D---E---F---G---H---I---J <master>


首先，如果
F--G--H
被挤压，那么
I--J
将是
I'--J'

鉴于此，我将首先创建一个分支，然后使用vanilla
git reset
然后
git cherry pick
：


# D---E---F---G---H---I---J master



  • git签出-b工作H
    
在
    H
    • 

  • git重置E
    
现在
    work
    位于
    E
    • 

  • git提交-am“F-G-H压缩为Z”
    
将
    F--G--H所做的更改提交为
    Z
    • 

  • git cherry pick I^..J
    
接管
    I--J
    • 
现在
    工作
    分支已达到您想要的形状，只需将
    主控
    重置为它：
    

    # D---E---Z---I`---J` work

git checkout master
git reset work
git branch -d work

    

    注意：提交范围已更正为
    I^..J
    ，以表示提交系列
    I--J
    （从
    I
    到
    J
    ，包括在内）
    你的第一个方法似乎是正确的开始，但是看起来Git认为你处于一个重置的中间。反直觉地，重置和合并是有状态的，Git可以在合并/重置结束之前把控制权还给你。试试<代码> Git ReBase-放弃/<代码>，然后再次执行那个命令。它看起来更像是<代码> G的输出。如果他指定了“编辑”，则显示状态
    对于一个提交。Git会说<代码>我想知道如果你在重新编译时正在键入<代码> Git ReBase是否在另一个RealBase<代码>的中间。有趣的方法，但是樱桃选择失败了。它似乎试图在<代码> Z 之后提交<代码>工作> <代码>。在我上面的回答中更新了。@Lucas，请尝试
    git cherry pick I^..J
    ，如果它有效，我会更新答案。在回顾git之后，这现在是有意义的。谢谢！而且，cherry pick在
    F
    上没有失败，而是在
    I2
    上失败，其中
    I2
    在
    I--I2--J
    中（我相应地更新了我的帖子）@Lucas，是的，它应该可以正常工作，因为这里的
    H
    和
    Z
    具有相同的内容，因此下面的所有提交都应该完全适用。@Lucas，不，提交哈希是提交本身及其父提交的结果。使用不同的父提交，新提交将不会具有相同的提交哈希。但是除了提交哈希，
    I'--J'
    与
    I--J
    完全相同。