签入应该是小步骤还是完整的功能?

DVCS系统的优点在于 二者都 因为DVCS不同于CVCS, 与…正交 . 在CVCS中,每个提交都是自动发布的,但在DVCS中,只有在提交时才发布 .

所以, 一小步,但只是 工作特性。

如果你担心污染你的历史,那么你可以重写它。你可能听说改写历史是邪恶的,但那不是真的:只有改写 出版

例如,Linux开发就是这样工作的。莱纳斯·托瓦尔兹非常关心保持历史的清白。在一封关于Git的早期电子邮件中,他说已经出版的历史应该不像你 但你是怎么做到的 会的 如果你无所不知,就可以预见未来,从不犯任何错误。

现在,Linux有点特别:它以每11分钟提交一次的速率进行提交,每天24小时,每周7天,一年365天,包括夜晚、周末、节假日和自然灾害。而且这个比率还在上升。试想一下,如果每一个打字错误和脑残都会导致提交,那么还会有多少提交。

但是开发人员自己在他们的私有存储库中提交的频率是他们想要的。

这两个世界都有可能做到最好,特别是在 git 以及其他DVCSs,让您可以选择要发布的历史。下面是一个简单的工作流程来说明这一点。

• 您的项目已完成 主人 分支机构。开发人员各自维护自己的 他们不推的树枝。

• 发展 做你的日常工作。小规模的提交出现在这里,表示随着时间的推移项目状态的增量进展。你可能会 主题-* 用于处理跨越几天以上的较长特性或主要重构的分支。你承诺 非常频繁,也许一小时几次。这就像在正在编辑的文档中点击“保存”。

• 释放 . 释放 现在有一堆个人提交被选择性地从您的 发展 分支机构。你承诺 释放 每当你到达一个好的停车点。通常是一天几次。

• 当发布准备就绪时,您的首席开发人员将压扁自上次合并到的所有提交 主人 主人

主人 这代表了自上次发布以来的变化。

小步走。这是有原因的 修订控制 ,而不是 释放控制 :)

你想做什么就做什么。不要退缩。在“进行中”分支上提交代码永远不会有负面影响。那些期望承诺不“破坏构建”的开发团队正在误用RCS。同样,归因 任何 名称

例如,您最不想做的就是制定一个策略来阻止开发人员提交他们的代码 任何 原因。

我非常喜欢Git的一点是,开发环境中的repo就是您的repo。这是维修人员回购的副本。你可以自由地做任何你想做的事,除非你推一些疯狂的历史记录,否则你不会离开维护者。

为此,尽可能多地使用分支和合并来帮助开发和实验。只把你最满意的改变推到上游。Git甚至可以在需要时将提交历史压缩成更少的更改集,这样就可以将执行的一系列提交推送到单个提交中。

这种灵活性极大地增强了您的个人工作流程以及您的同事制定的政策。

小步

我的同事很容易看出我的所作所为。 如果我工作三到四个小时,我通常更明智的做法是把半打承诺放在一边,这样我的同事就能看到相关的差异(我很感激他们对我同样的礼貌。)

最后,小步骤会减少冲突的可能性,或者当你这样做时,冲突会更小。

对于日常工作流程,小步骤有很多优点。如果你想要一个以分销为中心的工作流程,创建一个回购和一个只用于分销的分支,你可以按照你想要的方式在那里设置你的大步骤。

大多数情况下,我可以通过以下经验法则逃脱惩罚——在有意义的时候检查最小的数量(仍然是有用的或改进的)。我发现这有助于我更好地规划我的工作,这有几个好处,包括(但不限于)。。。

• 更好的发展预测。
• 更好的测试估计。
• 总体缺陷更少。
• 如果我的代码无意中破坏了其他东西,那就早点发现。
• 更多

但是,有时需要创建一个分支,然后在工作完成后,将其合并回主线。然而,一旦在分支机构进行操作,我仍然尝试遵循规则,因为它会自动放弃所有这些好处。

希望这有帮助。