git如何知道要保留哪个版本的行? [英] How does git know which version of a line to keep?
问题描述
我正在研究一个项目，该项目有时会以稳定版本发布.发布版本时，我们将从当前的HEAD开始开发下一个版本.
I am working a on project which is released in a stable version once in a while. When we release a version we start developing the next version from the current HEAD.
仍然支持旧版本，将其放在自己的分支上，并会收到各种较小的修复程序和功能.当我将修补程序应用于旧的受支持版本时，我(几乎)总是将它们也合并到当前版本中.
The old version is however is still supported, put on it's own branch and receives various minor fixes and features. When I apply a fix to an old supported version I (almost) always merge them into the current version as well.
工作流程示例
- 我的应用程序称为"libSSL".
- 我发布了libSSL版本2，并使用我发布的代码创建了一个单独的分支
- 我继续从libSSL版本2代码库开发libSSL版本3
- ....时间流逝.....
- 我修复了libSSL版本2中的一个关键安全问题
- 我将更改合并到当前代码中，以用于即将发布的libSSL版本3
我的情况
当我在git 这不是冲突，而只是一些代码说明.我更改了自上次发行以来(可能是很久以前)在某个时候制作的变量.
It's not a conflict but just some code clarification. I change in a variable which have been made at some point since the last release (probably a long time ago).
我的问题
git如何知道要使用哪个变量名?我猜git可以在进行更改时查找提交的时间戳(并选择最新的时间戳)，但这似乎是一项非常昂贵的任务，而且感觉并非如此.
How does git know which variable name to use? I guess git could look up the timestamp for the commit when the change was made (and pick the most recent one) but that seems like a very expensive task and it doesn't feel like that.
我通常不会对这些非冲突更改三思而后行，但是我可以确定git会做正确的事情吗?那是一个正确的假设，还是我应该更多地注意它们，以避免用旧代码覆盖某些新代码?
I normally don't think twice about these non conflict changes but can I be sure that git will do the right thing? Is that a valid assumption, or should I pay more attention to them in order to avoid overwriting some new code with some old code?
我总是将旧分支合并到新分支中.
I'm always merging the old branch into the new branch.
推荐答案
Git是一个内容可寻址的数据库，这意味着每个对象都存储在其内容的哈希值下. Git还可以进行三向合并.它找到合并基础"(甚至在git-merge-base-git help merge-base中还有一个命令来读取它)，该合并基础"找到了它们共同的最新祖先，即两者都在过去的某个时刻.
Git is a content-addressable database, meaning every object is stored under the hash of its contents. Git also does 3-way merges. It finds the 'merge-base' (there's even a command in git - merge-base - git help merge-base to read up on it) that finds the most recent ancestor that they have in common, i.e. the point that both forked off of at some point in the past.
与非哈希系统中需要比较文件以进行比较的非哈希系统中的3向合并不同，git可以查看3个散列.假设您要将功能合并到母版中.如果项目中文件的特定路径的3个哈希值相同，则跳过它-在任何一个分支中都没有更改-这非常快.如果哈希值在master上已更改，但在特性上未更改，则它仅使用master版本，因为有人在master上对其进行了更改，但没有人关注此功能，因此master版本是已更改/重要的版本.反之亦然，如果更改了功能，但未更改主功能，则仅使用功能版本.这也是超级快.实际上，大多数情况下这是大多数情况.大多数文件在较大的项目中不会更改，因此合并仅会比较两个分支中哈希值已更改的一小部分文件.
Unlike 3-way merges in non-hashed systems, which need to diff files for comparison, git can look at the 3 hashes. Let's say you're merging feature into master. If the 3 hashes of a particular path to a file in the project are identical, it skips it - it hasn't changed in either branch - this is super fast. If the hash has changed in master but not in feature, then it just uses the master version, because someone changed it on master, but no one cared to on feature, so the master version is the changed/important one. Vice-versa, if it changed in feature, but not in master, it just uses the feature version. This is also super fast. In fact, this is the majority case most of the time. Most files don't change in larger projects, so a merge only ends up comparing some small set of files for which the hash has changed in both branches.
如果两个分支中的哈希值都从两个分支的合并基础处的哈希值发生了变化，则git会退回到合并老式方法，逐行进行比较.如果一组行在一个路径中发生了变化，但在另一条路径中没有发生变化(与基于合并的副本相比)，则它将合并来自该分支的更改.如果您在两个分支中都更改了变量名，那么它将把它包装在冲突标记中，并告诉您需要手动解决，这是唯一的正确方法.正如Linus Torvalds所说，您不希望一台机器为您解决这个问题，而他是对的.
If the hash has changed in both branches from what it was at the merge-base of those two branches, then git falls back to merging the old-fashioned way, comparing things line-by-line. If one set of lines changed in one path, but not in the other (as compared to the merge-base copy), then it merges the changes from that branch. If you changed a variable name in both branches, then it would wrap it in conflict markers and tell you you need to resolve this manually, which is the only right way to do this. As Linus Torvalds said, you don't want a machine trying to figure that out for you, and he's right.
这篇关于git如何知道要保留哪个版本的行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
