我的工作流程中有许多短命分支,我希望它们能够分开.所以,我打算用git config --add merge.ff false.但是,当我正在进行拉(我理解为fetch + merge)时 - 然后我想要一个快进行为,以避免不必要的额外提交.
这是一件好事吗?这可能吗?
Von*_*onC 16
注意:Git 2.0(2014年第2季度)将引入提交b814da8配置push.ff:
pull.ff::
Run Code Online (Sandbox Code Playgroud)
默认情况下,Git在合并作为当前提交的后代的提交时不会创建额外的合并提交.相反,当前分支的提示是快进的.
- 当设置为false时,此变量告诉Git在这种情况下创建额外的合并提交(相当于从命令行提供--no-ff选项).
- 设置为only时,仅允许此类快进合并(相当于
--ff-only从命令行提供选项).
初步答复(2012年10月)
试试:
git pull --ff
Run Code Online (Sandbox Code Playgroud)
它应该优先于您的合并配置设置.
它会将--ff选项传递给git pull命令中的底层合并.
请注意该--no-ff选项,如" 了解Git工作流程 "中所述
有了足够的标记,你可以强制Git以你认为的方式行事而不是它想要的方式.但这就像使用像锤子一样的螺丝刀; 它完成了工作,但它做得很差,需要更长时间,并损坏螺丝刀.
考虑一下常见的Git工作流程如何分崩离析.
Create a branch off Master,
do work,
and merge it back into Master when you’re done
Run Code Online (Sandbox Code Playgroud)
大多数情况下,这种行为与您期望的一样,因为Master在您分支后发生了变化.然后有一天你将一个功能分支合并到Master中,但Master没有分歧.Git不是创建合并提交,而是将Master指向功能分支上的最新提交,或"快进".(图)
不幸的是,您的功能分支包含检查点提交,频繁提交以备份您的工作但捕获处于不稳定状态的代码.现在这些提交与Master的稳定提交无法区分.你可以很容易地重新陷入灾难.
因此,您添加了一条新规则:"当您在功能分支中合并时,使用
–no-ff强制执行新提交."这可以完成工作,然后继续.然后有一天你发现了生产中的一个关键错误,你需要追踪它何时被引入.你运行
bisect但继续登陆检查点提交.你放弃并手工调查.您将错误缩小到单个文件.你跑去
blame看看它在过去48小时里的变化情况.你知道这是不可能的,但blame报告文件几周没有被触及.
结果blame是初始提交时的报告更改,而不是合并时.您的第一个检查点提交在几周前修改了此文件,但此更改已于今天合并.该
no-ff创可贴,破平分,并指责奥秘是你使用螺丝刀作为锤子症状.
有关更多信息,请参阅
| 归档时间: |
|
| 查看次数: |
10074 次 |
| 最近记录: |