更改源格式时提交？
即使您只是更改空格、代码格式等内容，提交也是可以接受的做法吗？
Is it accepted practice to commit even when you're just changing things like whitespace, code formatting, etc.?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的。如果您需要进行空白更改，最好的做法是在仅包含此类清理的单独提交中进行这些更改。这避免了试图查看巨大差异的哪些部分是实际代码更改以及哪些部分只是格式（装饰）更改的问题。
也就是说，您应该尽量将此类更改保持在最低限度，并且仅在必要且与您的公司/社区/项目/等中使用的任何编码标准兼容时才进行更改。
Yes. If you need to do whitespace changes, doing them in a separate commit that contains only this kind of cleanup is the best practice. This avoids problems with trying to see what part of a giant diff is actual code changes, and what part is just formatting (cosmetic) changes.
That said, you should try to keep these kind of changes to a minimum, and only do it at all when it is necessary and compatible with whatever coding standards are used in your company / community / project / etc.
是的！是的！请作为单独的提交！
（这些类型的编辑往往会涉及大量代码，人们需要知道提交/更改集/补丁/其他内容是否纯粹出于重新格式化的原因，而不是对实际代码进行任何更改。）
Yes! Yes! As a separate commit, please!
(These kinds of edits tend to touch a lot of code, and people need to know if a commit/changeset/patch/whatever is there purely for reformatting reasons, with no change intended to the actual code.)
日安，
是的。但请以专用提交的形式进行，并附上一条消息，说明您已
没有什么比将格式更改与功能相结合更糟糕的了。更新，因此跨版本进行比较会导致信噪比很差！
顺便说一句，我想知道为什么要更改现有代码的格式。如果它一开始的格式就很糟糕，就不应该被签入！
没有什么比与那些出于其他原因而更改格式良好的源代码的人一起工作更糟糕的了，除了：
他们 “唯一真正的风格”的宗教表达通常掩盖了缺乏编码经验和团队合作经验。
HTH
欢呼，
G'day,
Yes. But please do it as a dedicated commit with a message stating that you've
Nothing worse than having formatting changes combined with functional updates so doing a diff across versions provides a poor S/N ratio!
As an aside, I'm wondering why you're making changes to the formatting of existing code. It shouldn't have been checked in if it was poorly formatted in the first place!
There's nothing worse than working with someone who goes through changing well-formatted source for no other reason other than:
Such religious expressions of "the one true style" usually belie a lack of coding experience and experience in working in a team.
HTH
cheers,
是的，只要所涉及的各个存储库之间存在一定的一致性，否则由于格式造成的冲突，这将使任何合并变得更加困难。
至少单独的提交有助于识别未来合并期间潜在冲突的真正来源。
如果它不是“您的”代码（即具有其他格式标准的其他存储库将必须合并回您正在做的事情），您可以利用 git 属性过滤器驱动程序及其涂抹/清理机制。
（来源：Pro Git 书籍： 自定义 Git - Git 属性)
您可以在涂抹步骤中将您的格式应用于代码，并在清理步骤中重新应用通用格式标准。
Yes, provided there is some consistency amongst the various repositories involved, otherwise that would make any merge that much more difficult to do, because of conflict due to formatting.
At least a separate commit helps identifying the real source of potential conflict during those future merge.
If it is not "your" code (i.e some other repo with some other formatting standard will have to merge back what you are doing), you could take advantage of the git attribute filter driver, and its smudge/clean mechanism.
(Source: Pro Git book: Customizing Git - Git Attributes)
You could apply your format to the code during the smudge step, and re-apply the common format standard during the clean step.
这里已经给出的答案很好地解释了为什么提交格式更改可能会出现问题。我认为一种解决方案是编辑器支持，允许人们在保存文件时看到格式良好的代码，同时最大限度地减少格式更改。
我在...
如果有任何好的答案，这个问题的查看者可能也会感兴趣。
The answers already here do a good job of explaining why it can be a problem to commit formatting changes. I think one solution would be editor support to allow one to see nicely formatted code while minimizing formatting changes when saving the file.
I've asked a related question about this in...
If any good answers come up there, viewers of this question may also be interested.