git如何知道要保留哪个版本的行？

Question

我正在开发一个项目，该项目偶尔以稳定版本发布。当我们发布一个版本时，我们开始从当前的HEAD开发下一个版本。

然而旧版本仍然受支持，加上它自己的分支并接收各种小修复和功能。当我将修复程序应用于旧的受支持版本时，我（几乎）总是将它们合并到当前版本中。

工作流程示例

1. 我的应用程序名为＆＃34; libSSL＆＃34;。
2. 我发布了libSSL版本2并使用我发布的代码创建了一个单独的分支
3. 我继续从libSSL第2版代码库开发libSSL第3版
4. ......时间过去.....
5. 我在libSSL第2版中修复了一个严重的安全问题
6. 我将更改合并到我即将发布的libSSL版本3
的当前代码中

我的情况

当我在git full res image here

中遇到这种情况时，我只是将旧支持版本的一些更改合并到我的最新分支中

这不是冲突，只是一些代码澄清。我改变了自上次发布以来某个时间点（可能是很久以前）的变量。

我的问题

git如何知道要使用哪个变量名？我猜git可以在进行更改时查找提交的时间戳（并选择最新的），但这似乎是一项非常昂贵的任务，并且它不会有这样的感觉。

我通常不会对这些非冲突变化三思而后行，但我能确定git会做正确的事情吗？这是一个有效的假设，还是应该更多地关注它们以避免用一些旧代码覆盖一些新代码？

我总是将旧分支合并到新分支中。

Answer 1

Git是一个内容可寻址的数据库，这意味着每个对象都存储在其内容的散列下。 Git也进行3向合并。它找到了'merge-base'（甚至在git中有一个命令 - merge-base - git help merge-base来读取它），找到它们共有的最新祖先，即两者都有在过去的某个时刻分开了。

与非散列系统中的三向合并（需要对文件进行比较以进行比较）不同，git可以查看3个散列。假设您正在将功能合并到主人身上。如果项目中文件的特定路径的3个哈希值相同，则会跳过它 - 它在任何一个分支中都没有更改 - 这是超快的。如果哈希在主服务器中已更改但在功能部件中没有更改，那么它只使用主版本，因为有人在主服务器上更改了它，但没有人关注功能，因此主服务器版本是已更改/重要的版本。反之亦然，如果它在功能上有所改变，但在主机中没有改变，它只使用功能版本。这也是超级快的。事实上，大多数情况下这是大多数情况。大多数文件在较大的项目中不会发生变化，因此合并只会比较两个分支中散列已更改的一小组文件。

如果哈希在两个分支中的变化与它们在这两个分支的合并基础上的变化一样，那么git会回归到合并旧的方式，逐行比较。如果在一个路径中更改了一组行，但在另一个路径中没有更改（与合并基础副本相比），则它会合并来自该分支的更改。如果您在两个分支中更改了变量名称，那么它会将其包装在冲突标记中并告诉您需要手动解决此问题，这是执行此操作的唯一正确方法。正如Linus Torvalds所说，你不希望机器试图为你解决这个问题，而且他是对的。