Git与--squash合并，同时保留每个提交的日志 [英] Git merge with --squash while keeping log of every commit

问题描述

初始方案:

A (master)
 \
 B - C  - D (development)

合并后我想要的-壁球:

What I want after merge --squash:

A     -     E (master/development)
 \         /
 B - C - D 

在分支master上，git log应该是

commit E
    Squashed commit of the following:
    commit D
    commit C
    commit B
commit A

继续在分支development上进行开发:

Keep developing on branch development:

A     -     E (master)
 \         / \         
 B - C - D    F - G - H (development)

再次与壁球合并:

A     -     E     -     I(master/development)
 \         / \         /
 B - C - D    F - G - H

在分支master上，git log应该是

commit I
    Squashed commit of the following:
    commit H
    commit G
    commit F
commit E
    Squashed commit of the following:
    commit D
    commit C
    commit B
commit A

在分支development上，git log应该是

Commit I
Commit H
Commit G
Commit F
Commit E
Commit D
Commit C
Commit B
Commit A

我想与压缩在master上的提交合并，同时将每个提交保留在development上.

I would like to merge with commits squashed on master while keeping every commit on development.

我不知道如何实现.我的问题是，在第一次合并中，我不知道如何使D指向E，并且I将包括B,C,D,E,F,G,H而不是仅包含F,G,H.

I have no idea how to implement that. My problem is that I don't know how to make D point to E in the first merge, and I will include B,C,D,E,F,G,H instead of F,G,H only.

推荐答案

您无法通过显示的结构获得所需的日志结果(git log --merges master可以做到).将为您提供所需日志的结构胜过一切.最后，这是与Git一起工作的自败之路.

You can't get the log result you want with the structure you showed (git log --merges master will sort of do it). The structure that will give you the log you want defeats the point. And, in the end, this is a self-defeating way to work with Git.

希望能够运行git log master并且仅查看压缩的提交.这行不通. Git不知道某些提交是针对master的，而有些则是针对development的.让我们看一下建议的结构.

The desire is to be able to run git log master and only see the squashed commits. This won't work. Git doesn't know that some commits are intended for master and some are for development. Let's look at the proposed structure.

A     -     E     -     I [master] [development]
 \         / \         /
 B - C - D    F - G - H

这时，master和development指向同一提交.就Git历史而言，它们是相同的.分支不过是指向提交的标签而已. 提交不记得他们提交了哪个分支. git log master和git log development将产生相同的日志，显示从A到I的所有提交.E和I压缩的提交日志将是多余的.

At this point, master and development point to the same commit. As far as Git history is concerned they are identical. A branch is nothing more than a label pointing at a commit. Commits don't remember what branch they were committed to. git log master and git log development will produce the same logs showing all commits from A to I. The E and I squashed commit logs will be redundant.

您可以使用git log --merges master(或development)获得想要的内容，以仅显示合并提交，但这将显示任何合并提交，即使已完成作为development的一部分.因此，它实际上不起作用.

You can get what you want with git log --merges master (or development) to show only merge commits, but that will show any merge commits, even those done as part of development. So it doesn't really work.

这整个想法不必要地复杂，请继续阅读.

This whole idea is unnecessarily complicated, read on.

要获得所需的日志结果，您需要像这样破坏两个分支之间的关系.

To get the log result you want, you'd have break the relationship between the two branches like this.

A     -     E     -     I [master]
 \                   
 B - C - D - F - G - H [development]

您可以通过某种方式进行工作，但没有意义. git log master包含所有相同的日志消息，因此与git log development一样长，但是它们将被粉碎在一起.您不能使用git log master进行代码考古(例如，为什么这样写这行代码")，因为所有更改都被粉碎到一个diff中，这使得将更改行与特定的提交消息关联起来更加困难.由于master和development的历史是不相关的，因此无法确保开发中的所有内容都成为母版，反之亦然(例如，母版的热修复程序).

Which you can make work somehow, but there's no point. git log master contains all the same log messages so it will be just as long as git log development, but they'll be smashed together. You can't use git log master to do code archaeology (ie. "why was this line written this way") because the changes are all smashed together into one diff making it harder to associate a line of change with a particular commit message. Since the history of master and development is disassociated, there's no way to ensure everything in development made it into master, or vice versa (for example, hot fixes to master).

git log master提供的信息比git log development少 ，并且难以理解. master与development没有关联，并且失去了保留合并历史记录的所有好处.维持这种复杂的设置毫无意义.

git log master provides less information than git log development and it's harder to understand. master has no association with development and loses all the benefits of keeping the merge history. There's no point in maintaining this complicated setup.

相反，使用git merge --no-ff合并功能分支(不是一个连续的开发"分支)，并保留分支历史以方便考古.

Instead, use git merge --no-ff to merge feature branches (not one continuous "development" branch) and keep the branch history for easy archaeology.

              G - J [feature/tacos]
             /
A     -     E     -     K [master]
 \         / \         /
 B - C - D    F - H - I

E和K是git merge --no-ff产生的正常合并提交.没有连续的development分支，该分支由要素分支处理.功能分支是一次性使用的，合并后将被删除.有关功能分支的信息保留在合并提交中，并且git merge --no-ff保证保留分支结构. feature/tacos是一个功能分支，可用于尚未合并的炸玉米饼.

E and K are normal merge commits produce by git merge --no-ff. There is no continuous development branch, that is handled by feature branches. Feature branches are single use and deleted once merged. The information about feature branches is preserved in the merge commit and git merge --no-ff guarantees the branch structure is preserved. feature/tacos is a feature branch to work on tacos that has not yet been merged.

git log --graph --decorate master将显示master的完整历史记录，合并提交显示要素何时结束，以及显示分支历史记录的行. GUI Git历史记录工具(例如 GitX )是将历史记录作为图形读取的另一种方式.

git log --graph --decorate master will show the complete history of master, with the merge commits showing when features ended, plus lines illustrating the branch history. A GUI Git history tool such as GitX is another way to read the history as a graph.

最后，Git历史记录是一个图形.如果您学习如何使用该图，则使用Git的生活会更加容易.如果您试图使Git的历史变得线性，就像一大堆煎饼，那么您就是在打破Git的观点，并为自己和其他人创造了更多的工作.

In the end, Git history is a graph. If you learn how to work with that graph life with Git will be much easier. If you try to make Git history linear, like a big stack of pancakes, you're defeating the point of Git and creating extra work for yourself and everyone else.

这篇关于Git与--squash合并，同时保留每个提交的日志的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！