更改源格式时提交？答案

【问题标题】：Committing when changing source formatting?更改源格式时提交？
【发布时间】：2010-02-06 19:49:53
【问题描述】：

即使您只是更改空格、代码格式等内容，是否也接受提交？

【问题讨论】：

【解决方案1】：

是的。如果您需要进行空白更改，最好在仅包含此类清理的单独提交中进行更改。这避免了尝试查看巨大差异的哪些部分是实际代码更改以及哪些部分只是格式（外观）更改的问题。

也就是说，您应该尽量减少此类更改，并且仅在必要且与您的公司/社区/项目/等中使用的任何编码标准兼容时才这样做。

【讨论】：

【解决方案2】：

是的！是的！请作为单独的提交！（这些类型的编辑往往会涉及大量代码，人们需要知道提交/变更集/补丁/其他内容是否纯粹是出于重新格式化的原因，而不是对实际代码进行任何更改。）

【讨论】：

【解决方案3】：

生日，

是的。但请作为一个专门的提交来做，并附上一条消息，说明你已经

没有什么比将格式更改与功能更新相结合更糟糕的了，因此跨版本进行差异会提供较差的 S/N 比！

顺便说一句，我想知道您为什么要更改现有代码的格式。如果一开始格式不正确，就不应该签入！

没有什么比与无缘无故更改格式良好的源代码的人合作更糟糕的了：

这种“一种真正的风格”的宗教表达通常掩盖了缺乏编码经验和团队工作经验。

HTH

干杯，

【讨论】：

【解决方案4】：

是的，只要所涉及的各个存储库之间存在一定的一致性，否则由于格式化导致的冲突，这将使任何合并变得更加困难。
至少一个单独的提交有助于识别未来合并期间潜在冲突的真正来源。

如果它不是“您的”代码（即其他一些具有其他格式标准的其他 repo 将不得不合并回您正在执行的操作），您可以利用 git attribute filter driver 及其涂抹/清洁机制。

您可以在涂抹步骤中将您的格式应用于代码，并在清洁步骤中重新应用通用格式标准。

【讨论】：

【解决方案5】：

此处已有的答案很好地解释了为什么提交格式更改会成为问题。我认为一种解决方案是编辑器支持，允许人们在保存文件时看到格式良好的代码，同时最大限度地减少格式更改。

我在...中问过一个相关的问题

如果那里有任何好的答案，这个问题的观众可能也会感兴趣。

【讨论】：