GitHub的“合并并压缩”合并方法 – “combine” 是什么意思?

huangapple go评论122阅读模式
英文:

Github's "squash and merge" merge method - what does "combine" mean?

问题

Github的文章关于合并方法陈述

不是查看贡献者的主题分支上的所有单个提交,而是将这些提交合并为一个提交,然后合并到默认分支。

该方法由下图示意,其中提交D和E被“合并”。

GitHub的“合并并压缩”合并方法 – “combine” 是什么意思?

问题是,文章中的“合并”提交是什么意思?

如果我理解正确,就Git而言,请纠正我,提交D的内容与结果提交F的内容(即工作树)没有任何相关性,对吗?

换句话说,在任何两种情况下,提交E具有相同内容而提交D不同的情况下,提交F将看起来相同,对吗?

英文:

Context

Github's article on merge-methods states

>Instead of seeing all of a contributor's individual commits from a topic branch, the commits are combined into one commit and merged into the default branch.

The method is illustrated by the following picture, where commit D and E are "combined".

GitHub的“合并并压缩”合并方法 – “combine” 是什么意思?

Question

What does the article mean by "combine" commits?

Please correct me if I am wrong, but as far as I understand git, the content of commit D has absolutely no relevance for the content (i.e. working tree) of the result-commit F, no?

Or in other words, in any two cases where commit E has the same content and commit D differs, commit F will look the same, right?

答案1

得分: 1

你的思维模式似乎是把提交看作是文件树,而不是一组更改,而这确实是Git的实现方式。因此,在这个意义上,你是对的,只有提交 E 的内容才重要。

然而,将提交视为一组更改时,更容易理解 "combine" 的含义:首先应用 D 中的更改,然后是 E 中的更改,然后得到的一组更改成为 F。

无论你如何看待它,F 的提交消息(默认情况下)将是 D 和 E 的提交消息的组合。

英文:

Your mental model seems to be that a commit is a tree of files, not a set of changes, and that's indeed how Git implements it. So in that sense, you are right that only the contents of commit E matter.

However, when viewing a commit as a set of changes, it's easier to see what "combine" means: first the changes in D are applied, then the changes in E, and the resulting set of changes becomes F.

However you view it, though, the commit messages for F will (by default) be the combination of the commit messages of D and E.

答案2

得分: 0

net changes from the squashed commits (D and E in the diagram) become a new single commit (F). Instead of putting two (or three, or four, or however many) incremental commits into main, we now have one new commit in main containing the sum of all changes from that other branch.

How F looks will depend on what happened in the other two:

  • if D has changes at the beginning of a file, and E has changes at the end of the same file, then F will be the changes at the beginning and end of that one file
  • if D changes one file, and E changes a different one, then F will have changes to both files
  • if D has a lot of work, and E is just a typo fix, then F will be all that work but with the fixed typo
  • if E overwrites everything in D, then F will just be the contents of E
  • etc.
英文:

The net changes from the squashed commits (D and E in the diagram) become a new single commit (F). Instead of putting two (or three, or four, or however many) incremental commits into main, we now have one new commit in main containing the sum of all changes from that other branch.

How F looks will depend on what happened in the other two:

  • if D has changes at the beginning of a file, and E has changes at the end of the same file, then F will be the changes at the beginning and end of that one file
  • if D changes one file, and E changes a different one, then F will have changes to both files
  • if D has a lot of work, and E is just a typo fix, then F will be all that work but with the fixed typo
  • if E overwrites everything in D, then F will just be the contents of E
  • etc.

huangapple
  • 本文由 发表于 2023年7月20日 17:40:26
  • 转载请务必保留本文链接:https://go.coder-hub.com/76728582.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定