git如何知道要保留哪个版本的行？
Mar*_*kus 5 git merge conflict
我正在研究一个项目,该项目偶尔以稳定版本发布.当我们发布版本时,我们开始从当前的HEAD开发下一个版本.
然而,旧版本仍然受支持,放在它自己的分支上,并接收各种小修复和功能.当我将修复程序应用于旧的受支持版本时,我(几乎)总是将它们合并到当前版本中.
工作流程示例
- 我的应用程序称为"libSSL".
- 我发布了libSSL版本2并使用我发布的代码创建了一个单独的分支
- 我继续从libSSL版本2代码库开发libSSL版本3
- ....时间流逝.....
- 我在libSSL版本2中修复了一个严重的安全问题
- 我将更改合并到我即将发布的libSSL版本3的当前代码中
我的情况
当我在git full res image中遇到这种情况时,我只是将旧的支持版本中的一些更改合并到我的最新分支中 
这不是冲突,只是一些代码澄清.我改变了自上次发布以来某些时间点(可能是很久以前)的变量.
我的问题
git如何知道要使用哪个变量名？我猜git可以在进行更改时查找提交的时间戳(并选择最新的),但这似乎是一项非常昂贵的任务,并且它不会那样.
我通常不会对这些非冲突的变化三思而后行,但我能确定git会做正确的事情吗？这是一个有效的假设,还是应该更多地关注它们以避免用一些旧代码覆盖一些新代码？
我总是将旧分支合并到新分支中.
Git是一个内容可寻址的数据库,意味着每个对象都存储在其内容的散列下.Git也进行3向合并.它找到了'merge-base'(甚至在git中有一个命令merge-base- git help merge-base读取它),它找到了他们共同拥有的最新祖先,即在过去的某个时刻分叉的点.
与非散列系统中的三向合并(需要对文件进行比较以进行比较)不同,git可以查看3个散列.假设您正在将功能合并到主人身上.如果项目中文件的特定路径的3个哈希值相同,则会跳过它 - 它在任何一个分支中都没有更改 - 这是超快的.如果哈希在主服务器中已更改但在功能部件中没有更改,那么它只使用主版本,因为有人在主服务器上更改了它,但没有人关注功能,因此主服务器版本是已更改/重要的版本.反之亦然,如果它在功能上有所改变,但在主机中没有改变,它只使用功能版本.这也是超级快的.事实上,大多数情况下这是大多数情况.大多数文件在较大的项目中不会发生变化,因此合并最终只会比较两个分支中散列已更改的一些小文件集.
如果哈希在两个分支中的变化都与它们在这两个分支的合并基础上的变化一样,那么git就会回归到合并旧的方式,逐行比较.如果在一个路径中更改了一组行,但在另一个路径中没有更改(与合并基础副本相比),则它会合并来自该分支的更改.如果您在两个分支中更改了变量名称,那么它会将其包装在冲突标记中并告诉您需要手动解决此问题,这是执行此操作的唯一正确方法.正如Linus Torvalds所说,你不希望机器试图为你解决这个问题,他是对的.