Git 补丁与钩子深度解析
1. Git 补丁相关内容
1.1 补丁作者和提交者信息
在 Git 中,补丁的作者和作者日期是根据原始提交和补丁来确定的,而提交者的数据则反映了应用补丁并将其提交到当前分支和仓库的操作。
1.2 糟糕补丁的问题
在全球多个分布式仓库中创建健壮且相同的内容是一项艰巨的任务,尽管当今的电子邮件系统存在诸多困难。一个原本良好的补丁可能会因各种与邮件相关的故障而被破坏。Git 有责任确保完整的补丁 - 邮件 - 应用周期能够通过不可靠的传输机制忠实地重建相同的内容。
补丁失败的原因有很多,包括工具不匹配和不同的理念。但最常见的失败原因可能是未能保持原始内容的精确行处理特性,这通常表现为由于发送方或接收方的邮件用户代理(MUA)或任何中间邮件传输代理(MTA)对文本进行重排而导致的换行问题。幸运的是,补丁格式有内部一致性检查,可以防止这种类型的失败破坏仓库。
1.3 打补丁与合并的区别
Git 可以处理在一个仓库中混合应用补丁和拉取相同更改的情况。即使接收仓库中的提交最终与创建补丁的原始仓库中的提交不同,Git 也可以利用其比较和匹配内容的能力来解决问题。
例如,后续的差异比较将显示没有内容更改。日志消息和作者信息也将与补丁邮件中传达的信息相同,但日期和 SHA1 等信息将不同。
直接获取并合并一个具有复杂历史的分支,将在接收仓库中产生与打补丁序列不同的历史记录。创建补丁序列的一个效果是将复杂分支的图进行拓扑排序,形成线性化的历史记录。因此,将其应用到另一个仓库会产生原始仓库中没有的线性化历史记录。根据你的开发风格和最终意图,在接