挑选并压缩一系列提交到一个子目录或子树中

我怎样才能告诉初选选择的提交范围和压缩它？

或者换句话说，对存储库的当前状态应用两次提交之间的区别？

以下是 没有的工作原理(初选框没有—— squash 选项) :

git cherry-pick --squash e064480..eab48b59c

注意: 我的用例在一个子树场景中——在有人开始争论我不应该压制之前。

下面的工作，但然后我有一个单独的提交范围。之后我可以用交互式 rebase 手动压缩它们。

git cherry-pick -X subtree=vendor/package e064480..eab48b59c

有什么办法可以把压扁作为采樱桃的一部分吗？

51117 次浏览
小开
最佳答案

Pass -n to git cherry-pick. This will apply all the commits, but not commit them. Then simply do git commit to commit all the changes in a single commit.

小开

Follow from master → cherry pick two commit from another branch

git checkout master
git cherry-pick :1
git cherry-pick :2
git reset --soft HEAD~2 (number of cherry pick commits, i.e 2 )
git add .
git commit
小开

Useful alternative vs git cherry-pick -n for some use cases might be git merge --squash - for example, when you want to test a feature branch's changes on top of your integration branch, without rebasing.

Source: What's the difference between git merge --squash and git cherry-pick?

小开
  1. Use git cherry-pick --no-commit <commit>…​.
  2. Resolve any conflicts.
  3. Commit.
  4. Continue with git cherry-pick --continue.
  5. Resolve any conflicts.
  6. Now amend changes to the previous commit.
  7. While git status shows Cherry-pick currently in progress. loop from step 4.
小开

From this 2022 discussion, there are other approaches:


  • But,

    • it does not show the commit messages,
    • you would not be able to use a graphical merge tool that shows the entire source file.
      When using "git cherry-pick" and there are conflicts, you can see the change in the context of the entire file.

  • Johannes Sixt suggests an interractive rebase

    To transplant the range A..B of the history on top of HEAD, for example, I'd start with (notice ^0 after B, as I do not trust myself so I'd leave the true branch B untouched as I may make mistakes while running rebase):

    $ git checkout --detach HEAD ;# this is only to use @{-1} later
$ git rebase -i --onto HEAD A B^0

    Then if my goal is to squash everything down into a single commit, then replace all 'pick', except for the first one, to 'squash'.
    That will give me one single chance to edit a single commit message, but the editor buffer starts with the log message from all of the original, so I can pick good bits from them while writing new stuff. I'll have the result on detached HEAD.
    If I like the result, I may update the branch I was originally on with it.

    $ git checkout -B @{-1}

    Or, if I don't, perhaps because I made mistakes, then I can just discard it and go back to the original branch.

    $ git checkout @{-1}

However, Noam Yorav-Raphael objects:

My main problem with using "rebase -i" is that it would require me to fix merge conflicts one by one, on each commit in which they appear, instead of fixing all conflicts at once, treating the change from A to B as one.
It also requires manual editing for every commit between A and B.

Noam proposes:

I think that the best way to do what I want using the existing commands is:

git checkout A
git merge --squash B
git commit --no-edit
git checkout @{2}            # Go back to where we were at the beginning.
# This is not exact, as you're in detached HEAD state.
git cherry-pick --edit @{1}  # cherry-pick the squashed commit A..B

This allows you to fix the merge conflicts in one go, shows the entire files causing the conflicts, and allows you to edit the commit message, starting with the descriptions of all the squashed commits.

I think this also gives a pretty good explanation of what "cherry-pick --squash" will do: it really is the analog of the "merge --squash", but for cherry-pick.


提交答案