在 git 中压缩提交是什么意思？

What does it mean to squash commits in git?

提问by Lakshmanan Meiyappan

What does Squashing commits in git mean. How do I squash commits in Github?

git 中的 Squashing commits 是什么意思。如何在 Github 中压缩提交？

I'm new to Git and I requested to be assigned to a newcomer bug in coala-analyzer. I fixed the bug, and now I was asked to squash my commits. How do I do it?

我是 Git 的新手，我请求被分配到 coala-analyzer 中的一个新人 bug。我修复了这个错误，现在我被要求压缩我的提交。我该怎么做？

回答by Margaret Bloom

You can think of Git as an advanced database of snapshots of your working directory(ies).

您可以将 Git 视为工作目录快照的高级数据库。

One very nice feature of Git is the ability to rewrite the history of commits.
The principal reason for doing this is that a lot of such history is relevant only for the developer who generated it, so it must be simplified, or made more nice, before submitting it to a shared repository.

Git 的一个非常好的特性是能够重写提交的历史。
这样做的主要原因是很多这样的历史只与生成它的开发人员相关，因此在将其提交到共享存储库之前，必须对其进行简化或改进。

Squashing a commitmeans, from an idiomatic point of view, to move the changes introduced in said commit into its parent so that you end up with one commit instead of two (or more).
If you repeat this process multiple times, you can reduce ncommit to a single one.

从惯用的角度来看，压缩提交意味着将所述提交中引入的更改移动到其父提交中，以便您最终得到一个提交而不是两个（或更多）。
如果多次重复此过程，则可以将n 个提交减少为一个。

Visually, if you started your work at the commit tagged Start, you want this

从视觉上看，如果你在标记为Start的提交开始你的工作，你想要这个

You may notice that the new commit has a slightly darker shade of blue. This is intentional.

您可能会注意到新提交的蓝色阴影略深。这是故意的。

In Git squashing is achieved with a Rebase, of a special form called Interactive Rebase.
Simplifying when you rebase a set of commits into a branch B, you apply all the changes introduced by those commits as they were done, starting from Binstead of their original ancestor.

在 Git 中，压缩是通过Rebase实现的，它是一种称为Interactive Rebase的特殊形式。
简化当您将一组提交变基到分支B 时，您可以应用这些提交在完成时引入的所有更改，从B而不是它们的原始祖先开始。

A visual clue

视觉线索

Note again the different shades of blue.

再次注意不同深浅的蓝色。

An interactive rebase let you choose how commits should be rebased. If you run this command:

交互式变基让您可以选择提交应如何变基。如果您运行此命令：

 git rebase -i branch

You would end up with a file that lists the commits that will be rebased

您最终会得到一个文件，其中列出了将重新定位的提交

 pick ae3...
 pick ef6...
 pick 1e0...
 pick 341...

I didn't name the commits, but these four ones are intended to be the commits from Startto Head

我没有名字的提交，但这些四个一意在将提交从开始到目

The nice thing about this list is that it is editable.
You can omit commits, or you can squash them.
All you have to do is to change the first word to squash.

这个列表的好处是它是可编辑的。
您可以省略提交，也可以压缩它们。
您所要做的就是将第一个单词更改为squash。

 pick ae3...
 squash ef6...
 squash 1e0...
 squash 341...

If you close the editor and no merge conflicts are found, you end up with this history:

如果您关闭编辑器并且没有发现合并冲突，您最终会得到以下历史记录：

In your case, you don't want to rebase into another branch, but rather into a previous commit.
In order to transform the history as shown in the very first example, you have to run something like

在您的情况下，您不想变基到另一个分支，而是想变基到先前的提交。
为了像第一个示例中显示的那样转换历史记录，您必须运行类似

git rebase -i HEAD~4

change the "commands" to squashfor all the commits apart from the first one, and then close your editor.

改变“命令”，以南瓜从第一个开了所有提交，然后关闭编辑器。

---

---

Note about altering history

关于更改历史记录的注意事项

In Git, commits are never edited. They can be pruned, made not reachable, cloned but not changed.
When you rebase, you are actually creating new commits.
The old ones are not longer reachable by any refs, so are not shown in the history but they are still there!

在 Git 中，提交永远不会被编辑。它们可以被修剪，使不可访问，克隆但不能改变。
当你变基时，你实际上是在创建新的提交。
旧的不再被任何 refs 访问，所以没有显示在历史中，但它们仍然存在！

This is what you actually get for a rebase:

这是您实际获得的变基：

If you have already pushed them somewhere, rewriting the history will actually make a branch!

如果你已经把它们推到了某个地方，重写历史实际上会产生一个分支！

回答by 0xAliHn

The rebase command has some awesome options available in its --interactive(or -i) mode, and one of the most widely used is the ability to squash commits. What this does is take smaller commits and combine them into larger ones, which could be useful if you're wrapping up the day's work or if you just want to package your changes differently. We're going to go over how you can do this easily.

rebase 命令在其--interactive（或-i）模式下提供了一些很棒的选项，其中最广泛使用的选项之一是压缩提交的能力。这样做是将较小的提交合并为较大的提交，如果您要结束一天的工作或者只是想以不同的方式打包更改，这可能会很有用。我们将讨论如何轻松做到这一点。

A word of caution:Only do this on commits that haven't been pushed an external repository. If others have based work off of the commits that you're going to delete, plenty of conflicts can occur. Just don't rewrite your history if it's been shared with others.

警告：仅对尚未推送到外部存储库的提交执行此操作。如果其他人的工作基于您要删除的提交，则可能会发生大量冲突。如果已与他人共享，请不要重写您的历史记录。

So let's say you've just made a few small commits, and you want to make one larger commit out of them. Our repository's history currently looks like this:

因此，假设您刚刚进行了一些小的提交，并且想要从中进行一次较大的提交。我们存储库的历史目前看起来像这样：

The last 4 commits would be much happier if they were wrapped up together, so let's do just that through interactive rebasing:

如果将最后 4 次提交打包在一起会更开心，所以让我们通过交互式 rebase 来做到这一点：

$ git rebase -i HEAD~4

pick 01d1124 Adding license
pick 6340aaa Moving license into its own file
pick ebfd367 Jekyll has become self-aware.
pick 30e0ccb Changed the tagline in the binary, too.

# Rebase 60709da..30e0ccb onto 60709da
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

So, a few things have happened here. First of all, I told Git that I wanted to rebase using the last four commits from where the HEAD is with HEAD~4. Git has now put me into an editor with the above text in it, and a little explanation of what can be done. You have plenty of options available to you from this screen, but right now we're just going to squash everything into one commit. So, changing the first four lines of the file to this will do the trick:

所以，这里发生了一些事情。首先，我告诉 Git，我想使用 HEAD~4 的 HEAD 所在位置的最后四个提交进行变基。Git 现在让我进入了一个编辑器，里面有上面的文本，还有一些可以做什么的解释。在这个屏幕上你有很多可用的选项，但现在我们只是要把所有的东西都压缩成一个提交。因此，将文件的前四行更改为此即可：

pick 01d1124 Adding license
squash 6340aaa Moving license into its own file
squash ebfd367 Jekyll has become self-aware.
squash 30e0ccb Changed the tagline in the binary, too.

Basically this tells Git to combine all four commits into the the first commit in the list. Once this is done and saved, another editor pops up with the following:

基本上这告诉 Git 将所有四个提交合并到列表中的第一个提交中。完成并保存后，另一个编辑器会弹出以下内容：

# This is a combination of 4 commits.
# The first commit's message is:
Adding license

# This is the 2nd commit message:

Moving license into its own file

# This is the 3rd commit message:

Jekyll has become self-aware.

# This is the 4th commit message:

Changed the tagline in the binary, too.

    # Please enter the commit message for your changes. Lines starting
    # with '#' will be ignored, and an empty message aborts the commit.
    # Explicit paths specified without -i nor -o; assuming --only paths...
    # Not currently on any branch.
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #   new file:   LICENSE
    #   modified:   README.textile
    #   modified:   Rakefile
    #   modified:   bin/jekyll
    #

Since we're combining so many commits, Git allows you to modify the new commit's message based on the rest of the commits involved in the process. Edit the message as you see fit, then save and quit. Once that's done, your commits have been successfully squashed!

由于我们合并了如此多的提交，Git 允许您根据流程中涉及的其余提交修改新提交的消息。编辑您认为合适的消息，然后保存并退出。完成后，您的提交已成功压缩！

Created commit 0fc4eea: Creating license file, and making jekyll self-aware.
 4 files changed, 27 insertions(+), 30 deletions(-)
  create mode 100644 LICENSE
    Successfully rebased and updated refs/heads/master.

And if we look at the history again…

如果我们再看一遍历史……

So, this has been a relatively painless so far. If you run into conflicts during the rebase, they're usually quite easy to resolve and Git leads you through as much as possible. The basics of this is fix the conflict in question, git addthe file, and then git rebase --continuewill resume the process. Of course, doing a git rebase --abortwill bring you back to your previous state if you want. If for some reason you've lost a commit in the rebase, you can use the reflog to get it back.

所以，到目前为止，这一直是一个相对轻松的过程。如果您在变基期间遇到冲突，它们通常很容易解决，并且 Git 会尽可能多地引导您完成。其基础是修复有问题的冲突，git add文件，然后git rebase --continue将恢复该过程。当然，git rebase --abort如果你愿意，做 a会让你回到以前的状态。如果由于某种原因您在 rebase 中丢失了一个提交，您可以使用 reflog 将其取回。

Details can be found this link.

详细信息可在此链接中找到。

回答by Julien Lopez

It means combining several commits into one. Have a look at :

这意味着将多个提交合并为一个。看一下 ：

https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/

https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/

Squash my last X commits together using Git

使用 Git 压缩我最后的 X 提交