假设我编写了代码的原子更改。我还编写了一些测试以确保更改有效并继续有效。
我认为我应该将代码更改与测试一起提交。
亲:
- 这确保(尽可能)分支的每个变更集都会导致运行代码并通过测试。
- 它记录了这些测试“属于”我所做的代码更改。
缺点:
- 我可能想在将来的某个时间退出更改而不退出测试
以一种或另一种方式做这件事还有什么理由?任何一种策略都曾让你吃过苦头吗?具体如何?
假设我编写了代码的原子更改。我还编写了一些测试以确保更改有效并继续有效。
我认为我应该将代码更改与测试一起提交。
亲:
缺点:
以一种或另一种方式做这件事还有什么理由?任何一种策略都曾让你吃过苦头吗?具体如何?
My only rule is to make sure that code builds prior to checking in.
Yes, ideally you want to check in atomic bits of code. However, how do you define atomic? And then what happens if, later, you have to change one of the bits? Your changes are no longer in one commit.
我认为我应该将代码更改与测试一起提交。
我从不这样做,但如果我使用非分支 SCM,我会这样做。
在分支 SCM(我使用过 mercurial 和 git)中,这不是问题。
每次我开始工作时,我都会使用不同的分支;我很多时候有本地分支提交,当我移动到其他东西一段时间时,或者当我在开始重大代码更改之前只需要一个备份点时,只提交未完成的更改(甚至不编译)。我知道,当我创建它们时,大多数中间提交将永远不会被再次签出。它们不会影响任何东西,并且在需要时非常有用。
只有当我有可以在其上成功运行的编译和测试代码时,我才会合并分支。