是否将重构和非重构更改作为单独的签入?

当我记得的时候,我喜欢在重构之后签入以准备添加一个特性。通常,它会使代码处于更好的状态,但不会改变行为。如果我决定放弃这个特性,我总是可以保留结构更好的代码。

保持简单。

每次签入都应该是对代码库的一个独特的、单一的、增量的更改。

这使得跟踪更改和理解代码发生了什么事情变得容易得多,尤其是当您发现上个月11号某个地方出现了一个模糊的bug时。试图在300个文件重构签入过程中找到一行更改,真的,真的很糟糕。

通常,当我完成了某个工作单元时,我会签入,代码返回编译状态/单元测试是绿色的。这可能包括重构。我想说,最好的做法是把它们分开。我发现这很难用我的工作流程来完成。

我同意先前的回答。如果有疑问,请将您的更改拆分为多个提交。如果您不想用许多小的变更(并且让您的修订显示为一个原子变更)来混乱变更历史,那么可以在一个分支中执行这些变更,在这个分支中您可以将它们拆分。如果每一个变化都是清晰和可理解的,那么以后阅读这些差异就容易多了(并且可以放心,没有任何东西是无意中损坏的)。

不要在修复格式的同时更改功能。如果您更改了条件的含义,使一整批代码都可以过时,那么可以在一次更改中更改逻辑,并在随后的更改中执行过时。和 明确您的提交消息 .

如果源代码控制系统允许。 (由于源代码控制系统不喜欢单个用户将单个文件签出到多个位置,因此在我当前的作业中无法执行此操作。)

• 我有两个工作文件夹
• 两个文件夹都从同一分支签出
• 我使用一个文件夹来实现新的功能开发/错误修复更改
• 在另一个文件夹中,我进行重构,
• 每次重构之后,我都会检入重构文件夹。
• 然后更新合并到重构中的新功能开发文件夹

因此,每个重构都在自己的签入和其他开发人员中。 快速得到重构,这样就减少了合并问题。 .