理解Git Workflow文章说,
因此,您添加了一条新规则:"当您在功能分支中合并时,请使用-no-ff强制执行新提交."这样可以完成工作,然后继续.
然后有一天你发现了生产中的一个关键错误,你需要追踪它何时被引入.你运行bisect但继续登陆检查点提交.你放弃并手工调查.
您将错误缩小到单个文件.在过去的48小时里,你一直负责看看它是如何变化的.你知道这是不可能的,但是责备报告文件在几周内没有被触及.事实证明,责备报告了初始提交时间的变化,而不是合并时的变化.您的第一个检查点提交在几周前修改了此文件,但此更改已于今天合并.
没有ff的创可贴,破碎的二等分和责备神秘都是你用螺丝刀作为锤子的症状.
--no-ff当您明确阻止快进合并时,git merge 就是一种情况.但是,如果一个提交不是另一个提交的直接祖先,那么快进甚至不会发生.这是一个罕见的开发方案.换句话说,大多数合并都是非快进类型.那么如何通过--no-ff打破的功能bisect和blame？
合并提交,并--no-ff没有什么关系git bisect或git blame 本身.
混合公共和私人历史使得更难理解不同提交所引入的变化.在使用git bisect和git blame调试时,这变得非常明显.
git bisect正如@torek所说,通过传递强制创建合并提交--no-ff并没有做任何事情git bisect.
真正的问题来自于使用临时提交(有时称为检查点提交)来污染存储库的公共历史,程序员使用这些提交来在本地跟踪他们自己的工作.
由于它们的临时性质,这些提交往往是不一致的 - 可能在代码库中引入错误 - 并且记录不足.在调试会话中着陆这样的提交git bisect并不是一种愉快的体验; 补丁可能很难解释,或者 - 更糟糕的是 - 它可能会破坏工作树中的代码.
我认为 Linus Torvalds 说得最好:
我想要干净的历史,但这确实意味着(a)清洁和(b)历史.
关于"清洁"部分,他继续详细说明:
保持自己的历史可读性.
有些人通过首先解决问题,而不是犯错误来做到这一点.但这是非常罕见的,对于我们其他人来说,我们在处理问题的同时使用"git rebase"等.
不要暴露你的垃圾.
git blame当涉及到git blame,合并提交做,其实对你得到的结果产生影响.
git blame始终显示给定代码行的原作者 ; 换句话说,谁将其添加到文件中.从Git的角度来看,合并提交不会向文件添加任何内容,它只是表示存储库的目录和文件的快照,这些目录和文件是由两行或多行历史记录组合而成的.除非它是一个邪恶的合并,就是这样.
这意味着git blame在合并文件上运行将向您显示每行的原始作者,无论谁进行了合并提交.
这就是为什么合并提交会使跟踪谁做出特定更改以及何时更难的原因.但话说回来,你不应该把私人提交合并到公共分支机构,因为除了原作者之外,其他任何人都没有意义.
京公网安备 11010802040832号 | 京ICP备19059560号-6 