即使您只是在改变诸如空白,代码格式等内容时,是否接受实践?更改源格式时提交吗?
回答
是的。如果您需要执行空白更改,则在仅包含此类清理的单独提交中执行这些更改是最佳做法。这可以避免尝试查看实际代码更改的巨大差异的哪些部分存在问题,以及哪些部分只是格式化(整体)更改。
这就是说,你应该尝试这些样的变化保持在最低限度,只有做到这一点在所有的时候是必要的,兼容任何编码标准在贵公司/社区/项目中使用/等
是的,只要所涉及的各个存储库之间存在某种一致性,否则会由于格式化而产生冲突,使得任何合并更加困难。
至少有一个单独的提交有助于识别未来合并期间潜在冲突的真实来源。
如果它不是“你的”代码(即其他一些其他格式化标准的回购将不得不合并你所做的),你可以利用git attribute filter driver及其涂抹/清除机制。
(来源:Pro Git book:Customizing Git - Git Attributes)
在涂抹步骤中,您可以申请您格式的代码,并在清洗步骤重新申请的通用格式标准。
是的!是!作为一个单独的提交,请! (这些类型的编辑往往会触及很多代码,并且人们需要知道提交/更改集/修补程序/是否纯粹出于重新格式化的原因,而没有针对实际代码进行更改)。
G '天,
是的。但请不要作为一个专门用一条消息,说明你已经
- 更改后的格式提交,
- 通过代码格式化,例如运行代码Perltidy,有关实际使用的设置的说明,
- 等
什么比格式更改与功能更新,这样做跨版本差异提供了一个可怜的S/N比合并更糟糕!
顺便说一下,我想知道为什么要对现有代码的格式进行更改。它不应该被检入,如果它格式不好,首先!
没有什么比别人谁经历改变格式良好的来源没有其它的原因,而不是工作更糟:
-
他们认为
- 括号属于对“如果”语句的行,或
- 他们不喜欢 “拥抱别人的”,或
- 等
- 等
这样的宗教表述“一个真正的风格“通常认为缺乏在团队中工作的编码经验和经验。
HTH
欢呼声,
的答案已经在这里做解释为什么它可以提交格式更改问题的一个好工作。我认为一种解决方案是编辑器支持,以允许用户在保存文件时查看格式良好的代码,同时最小化格式更改。
我问过一个相关的问题关于这...
如果有好的答案来了那里,这个问题的观众可能也有兴趣。
- 1. 更改源提交
- 2. Kendo DateTimePicker在提交后更改格式
- 3. Rails:提交更改表格
- 4. 以HTML格式提交时更改图像
- 5. 提交时更改日期选择器格式(JS)
- 6. LINQ提交更改不提交更改
- 7. 格式提交JSON格式提交
- 8. 何时提交更改?
- 9. 海关提交对开源项目的更改吗?
- 10. 时间格式提交
- 11. 提交更改
- 12. 更改提示格式
- 13. 提交时改变图片来源
- 14. 在extjs roweditor网格上提交更改
- 15. 提交后更改表格的目标
- 16. 更改提交表格的内容提交
- 17. 更改提交者
- 18. gldatepicker更改提交
- 19. 提交更改CVS
- 20. LostFocus提交更改
- 21. 更改消息以Umbraco形式提交
- 22. 使用TortoiseSVN提交时可以更改服务器地址吗?
- 23. 只提交格式更改的文件,如何删除?
- 24. 在提交之前更改表格的形式
- 25. Telerik MVC Grid提交更改没有网格更改
- 26. 当字段更改时提交AJAX表格
- 27. 提交新版本时iOS更改价格
- 28. 更改时间格式PHP
- 29. 更改时间格式
- 30. 更改时间格式