Git：压缩不是最近提交的连续提交，并且不要从根开始 [英] Git: Squashing consecutive commits that are not the most recent commits, and do not start at the root

问题描述

我回顾了几个与相关的问题最近的提交和压缩提交根目录，但这两者都不能帮助我压缩不属于根的非近期提交。

这是我的开始场景：

  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正在进行中;到D 
上您目前正在编辑提交，同时在'D'上重新设定分支'master'。 
 
没有变化
您要求修改最近的提交，但这样做会使
变空。您可以使用--allow-empty重复您的命令，或者您可以
完全使用git reset HEAD ^删除提交。 
 
无法应用F ...提交F的评论
 
 [1] +完成gitk 
 [lucas] / home / blah / $ 
  

其中我选择提交 F --- G --- H 变为 squash ，同时将最老的提交 - 交叉转换交互中的第一行 - 作为 pick 。为什么这不起作用？

更新：在命令结束时，正在进行重新生成 D 与 E 是HEAD提交。可以肯定的是，在开始时没有任何rebase正在进行，并且在再次运行时调用 git rebase --abort 具有相同的结果。当我在root或HEAD上执行此操作时，根据以上链接，一切正常。

第二种方法：

我做了另一次尝试[通过合并一个新分支（论坛上的最后一篇文章）] [ http://git.661346.n2.nabble.com/Non-interactive-squash-a-range-td5251049.html ）它使用 git checkout -b< clean-branch> <启动-ID>和 git merge --squash`，但我得到以下内容：

  [lucas-ThinkPad- W520] / home /.../。Solstice_WS / 7K_FGHF $ git checkout -b clean-branch D 
转换到分支'clean-branch'
 [lucas-ThinkPad-W520] / home / .. ./.Solstice_WS/7K_FGHF$ git merge --squash I 
更新D..I 
快进
壁球提交 - 不更新HEAD 
 ... / GraphUtilities / impl / DAG.java | 7 ++ ----- 
 1个文件已更改，2个插入（+），5个删除（ - ）
 [lucas] / home / blah / $ git checkout master 
错误：Your以下文件的本地更改将被checkout覆盖：
 asdf / GraphUtilities // DAG.java 
请在提交更改或隐藏它们，然后才能切换分支。 
正在取消
  

这似乎有这样的结果：

  -------------------< clean-branch>与未提交的变更
 / 
 D --- E --- F --- G --- H --- I --- J< master> 
  

我有点难住，所以我怎么挤压这些提交？

最终，我打算在 JGit 中实现它，所以 JGit 实现将是可以接受的。

注意 可能有一个在这里复制，但它没有答案，我认为这个问题有点儿不清楚。

更新

这是对@ ryenus的回答： p>

在提交 I2 时，cherry-pick失败，其中 I2 在 I --- I2 --- J 中。当它失败时，我的 work 分支的状态具有 D --- E --- Z 直到挑选樱桃，然后进行未经许可的更改。调用 git cherry-pick --abort 会清除这些未提交的更改，并验证提交 Z 是否正确，即南瓜的 F --- G --- H 。在提交 Z 后，选择樱桃，为什么樱桃选择在 F ？

看起来好像 git cherry-pick I ... J 试图挑选 I2 ，这会创建合并冲突并失败。任何建议？

这是我的输出：

$ $ p $ [lucas] / home $ git checkout -b work H
切换到新分支'work'
[lucas] / home $ git reset E
复位后的未暂停更改：
M adf / GraphUtilities // graph / impl / DAG.java
[lucas] / home $ git commit -am在这里压扁提交！
[work Z]压扁了！
1个文件已更改，2个插入（+），5个删除（ - ）
[lucas] / home $ git cherry-pick I ... J
错误：无法应用I2 .. 。<来自提交I2的评论>
提示：在解决冲突之后，将校正后的路径标记为
hint：使用'git add <路径>'或'git rm <路径>'
hint：并将结果提交给'git commit'
[lucas] / home / $ git status
分支作业
您目前正在进行樱桃采摘提交I2。
（修复冲突并运行git cherry-pick -continue）
（使用git cherry-pick --abort取消樱桃挑选操作）

未合并路径：
（使用git add< file> ...标记分辨率）

都已修改：3b6863741967406c1888701eb139178187d429487b99787096441d67bed56 / Gra
phUtilities / src / edu / washington / cs / utils / graph / impl / DAG.java

没有更改添加到提交中（使用git add和/或git commit -a）
[lucas] / home $


解决方案

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

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

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

1. git checkout -b work H
   

   创建分支 code> at H work 位于 E




2. git commit -amFGH squeezed as Z
   

   提交由 F --- G --- H 作为 Z




3. git cherry-pick I ^ .. J
   

   接管 I --- J

现在， work 分支处于所需的形状，只需重置 master ：



 ＃D --- E --- Z --- I` --- J`工作
 
 git checkout master 
 git reset work 
 git branch -d work 
  


$ b $注意：提交范围已被更正为 I ^ .. J ，以表示提交系列 I --- J code>（从 I 到 J ，包括$）。

I have reviewed several related questions about squashing the most recent commits and squashing a commit at the root, but neither will help me squash non-recent commits that are not at the root.

Here is my starting scenario:

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

and my desired result:

D---E---Z---I---J master

where Z is the squash of F---G---H, and F---G---H, D---E, and I---J can be an arbitrarily long sequence of non-branching commits.

First approach:

[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/$ 

where I select commits F---G---H to be squash, while leaving the oldest commit - the first line in the rebase interactive - as pick. Why doesn't this work?

Update: at the end of the command, a rebase is in progress on D with E being the HEAD commit. To be sure, there was no rebase in progress at the start and calling git rebase --abort while running again has the same result. When I do this at root, or HEAD, according to the links above, everything works fine.

Second approach:

I made another attempt [via merging a new branch (last post on the forum)][http://git.661346.n2.nabble.com/Non-interactive-squash-a-range-td5251049.html) which uses git checkout -b <clean-branch> <start-id> andgit merge --squash `, but I get the following:

[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

which seems to have this result:

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

I am a bit stumped, so how can I squash these commits?

Ultimately, I plan to implement this in JGit, so a JGit implementation would be acceptable as well.

NOTE

There may be a duplicate here, but it has no answers and I think the question is a bit unclear.

UPDATE

This is in response to @ryenus's answer below:

The cherry-pick fails on the commit I2, where I2 is in I---I2---J. When it fails, the state of my work branch has D---E---Z, as intended up until the cherry-pick, and it is followed by uncommitted changes. Calling git cherry-pick --abort clears these uncommitted changes, and I verified that commit Z is correct, which is the squash of F---G---H. After committing Z, then cherry-picking, why does the cherry-pick fail at F?

It seems as though git cherry-pick I...J is trying to cherry-pick I2, which creates the merge conflict and fails. Any suggestions?

Here is my output:

[lucas]/home$ git checkout -b work H
Switched to a new branch 'work'
[lucas]/home$ git reset E             
Unstaged changes after reset:
M       adf/GraphUtilities//graph/impl/DAG.java
[lucas]/home$ git commit -am "squashed commit here!"
[work Z] squashed commit here!
 1 file changed, 2 insertions(+), 5 deletions(-)
[lucas]/home$ git cherry-pick I...J
error: could not apply I2... <Comments from commit I2>
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
[lucas]/home/$ git status
On branch work
You are currently cherry-picking commit I2.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      3b6863741967406c1888701eb139178187d429487b99787096441d67bed56/Gra
phUtilities/src/edu/washington/cs/utils/graph/impl/DAG.java

no changes added to commit (use "git add" and/or "git commit -a")
[lucas]/home$ 

解决方案

First of all, if F---G---H are squashed, then I---J would be I'---J'.

Given that, I'd create a branch first then use vanilla git reset then git cherry-pick:

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

1. git checkout -b work H

   create branch work at H

2. git reset E

   now work is at E

3. git commit -am "F-G-H squeezed as Z"

   commit the changes done by F---G---H as Z

4. git cherry-pick I^..J

   take over I---J

Now the work branch is in the shape you want, just reset master to it:

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

git checkout master
git reset work
git branch -d work

Note: the commit range has been corrected to I^..J, to represent the commit series I---J (from I to J, inclusive).

这篇关于Git：压缩不是最近提交的连续提交，并且不要从根开始的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！