blocks|key|1530453|text|如果您要更改代码文件，我不太明白您为什么不想提交和共享这些更改。如果你不这样做，你就会冒着风险，别人会修好它们，然后和你的撞在一起。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1530454|如果它们不是其他用户想要的代码库中的更改，也许您应该问问自己，为什么要花时间编写它们。|1530455|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you are changing the code file, I don't really see why you wouldn't want to commit and share those changes. If you don't you run the risk that someone else will fix them and then collide with yours.

If they aren't changes that other users want in the codebase, perhaps you should ask yourself why you are spending time writing them.

blocks|key|1530569|text|一定要提交它们，并适当地标记提交注释，以便在浏览更改列表时更容易忽略。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1530570|不要将它们提交到与更改功能相同的操作中。这样，如果您确实破坏了某件东西，就更容易缩小破坏它的范围，并且在必要时很容易恢复重构。|1530571|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Do commit them, with the commit comment flagged appropriately to make it easier to ignore when skimming through a list of changes.

Don't commit them in the same operation as a change to functionality. That way, if you do break something, it is easier to narrow down what broke it and is easy to revert just the refactoring if necessary.

blocks|key|1562498|text|不要将它们与无关的修复一起提交。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562499|我会提交它们，但是在提交消息中添加一些预定义的关键字。在生成更改日志时，可以忽略带有此关键字的消息。|1562500|例如，您可以使用像[cleanup]这样的前缀。|offset|length|style|CODE|1562501|[cleanup]+Removed+some+whitespace
[cleanup]+Changed+format
Fixed+some+major+bug.
[cleanup]+Corrected+indentation|code-block|syntax|javascript|1562502|entityMap^0|0|0|9|9|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|J|3|K|5|L|7|V|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Don't commit them together with unrelated fixes.

I would commit them, but add some predefined keyword to the commit message. Messages with this keyword could then be ignored when generating change logs.

You could use a prefix like <code>[cleanup]</code> for instance.

<pre><code>[cleanup] Removed some whitespace
[cleanup] Changed format
Fixed some major bug.
[cleanup] Corrected indentation
</code></pre>

blocks|key|1562521|text|在我是唯一的开发人员的项目中，我倾向于与其他代码更改一起进行这类修复。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562522|在我们有一个团队的项目中，我倾向于尝试自己做出这样的改变，这样它们就不会掩盖“真正的工作”。|1562523|我觉得用代码库来修复所有“错误”的东西是很重要的，即使它只是简单的小事情，比如缩进。|1562524|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

On projects where I'm the only developer I tend to do these kind of fix ups along with other code changes.

On projects where there's a team of us I tend to try and commit these kind of changes on their own so that they don't obscure the 'real work'.

I feel that it's important to fix everything that's 'wrong' with a codebase even if it's purely minor things like indentation.

blocks|key|738905|text|我认为这取决于您的工作环境，以及在同一项目中工作的其他人希望如何处理可能存在差异的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|738906|所以，我的一般建议是问那些使用相同代码的人，并给出类似案例的指导方针。你可能会发现，人们不介意因为表面上的变化而进行检查，或者他们宁愿生活在“不漂亮”的环境中，也不愿处理杂乱无章的更改日志。|738907|明确的指导方针对每个人都是透明的，是处理这些问题和避免今后出现混乱的最佳方法。|738908|就我个人而言，我喜欢整理代码和不介意签入，因为纯粹的化妆品变化。然而，如果它只是一些间隔和换行，我可能只是让它和只有当我正在处理相同的代码文件时才会改变它。我经常删除和排序用法，因为我发现如果有一大堆用法没有意义，我会感到困惑，但那只是我自己。|738909|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I think this depends on your work environment and how others working on the same project want to deal with that which is likely to differ.

So, my general suggestion would be to ask the people working with the same code and coming up with a guideline for cases like that. You might find that people don't mind check-ins due to cosmetic changes or that they would rather live with a bit of "unprettiness" rather than dealing with cluttered change logs.

A definitive guideline that is transparent to everyone is the best way to deal with these questions and avoid confusion in the future.

Personally, I like tidied up code and wouldn't mind check-ins due to purely cosmetic changes. However, if it is just a bit of spacing and line breaks, I would probably just let it be and only change it if I was working on the same code file anyway. I often remove and sort usings because I find it confusing if there are a whole bunch of usings that don't make sense, but that's just me.

blocks|key|1562702|text|有几个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562703|首先，不要因为无聊和没有足够的实际任务而更改代码。如果是这样的话，去和你的项目经理谈谈，得到一些真正的任务，有价值的东西。|1562704|换句话说，不要为了更改而更改代码。始终在处理过程中向代码添加一些值。|1562705|现在，如果这些更改有助于您和其他人更容易地处理代码，那么就执行它们。比如确保遵守命名标准，重构代码等等。但是要为它找到一个任务，这样你的项目经理就可以说“是的，这很好，花两个小时在这上面，然后给我回电话。”|1562706|当你完成这些改变时，就把它们提交给你。不要将它们与您在前面完成的任何实际任务或下一个任务结合在一起，这将使分支、代码评审和普通代码浏览之间的合并错误难以理解。|1562707|1562708|+"Ok，所以您修复了bug+7711，并且还更改了大约100个其他文件。很好，那么这里的错误修复实际上是什么呢？“|blockquote|1562709|
。|1562710|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

There's a couple of issues.

First, don't do changes to the code because you're bored and doesn't have enough real tasks. If this is the case, go talk to your project manager and get some real tasks assigned to you, something with value.

In other words, don't go changing the code for the sake of the change. Always add some value to the code in the process.

Now, if those changes are contributing to making the code easier to handle, by you, and others, then do them. Things like ensuring naming standards are followed, refactor crufty code, etc. But get a task for it, so that your project manager can say "Yes, this is good, spend 2 hours on this and get back to me."

Commit the changes when you're done with them. Don't lop them together with whatever real task you finished just before them, or the next one, it will make merging bugfixes between branches, code reviews, and just general code browsing, hard to follow.

<blockquote>
 "Ok, so you fixed bug 7711, and also changed about 100 other files. Nice, so what is actually the bugfix here?"
</blockquote>

blocks|key|1562691|text|一定要把他们交出来。如果您将它们与真正的代码更改一起提交，并且必须回滚这些更改，那么您将失去您的修补程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562692|理想情况下，提交应该像数据库事务一样:一个相关的工作代码块可以回滚，而不会影响系统的其他部分。|1562693|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Definitely commit them. If you commit them along with real code changes and you have to roll back those changes, then you lose your cosmetic fixes.

Ideally, commits should be like database transactions: a chunk of related working code that can be rolled back without affecting the rest of the system.

blocks|key|1562715|text|如果更改可能以任何方式引起争议(例如括号的位置)，那么请确保您已经与团队的其他成员商定了一种代码样式。不要仅仅将其更改为您自己喜欢的样式，然后签入。否则其他人可能会把它改回来并检查他们的变化，然后你把它改回你的方式.|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562716|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If the changes are to things which might be in any way controversial (position of brackets for example) then make sure you've agreed a code style with the rest of your team. Don't just change it to your own preferred style then check it in. Otherwise someone else might then change it back and check their changes in, then you change it back to your way...

blocks|key|735839|text|这些“小”的东西能治好吗？如果是，就把他们交出来。如果没有，就不要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|735840|真的，这取决于你和你的团队认为什么是重要的。|735841|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Are these "minor" things fixes? If yes, commit them. If no, don't.

Really, it depends on what you and your team consider important.

blocks|key|1530619|text|我喜欢经常承诺。当然，任何时候都会有明显的变化。那样很容易。如果您开始划分代码片段，并尝试尽早提交一些代码片段，那么您最终会忘记提交一些非常重要的内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1530620|简而言之:经常提交，并且总是记录更改。当有一个巨大的变化，标记它。|1530621|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

i like to commit often. Certainly any time there's an appreciable change. It's easy that way. If you start to compartmentalize code snippets and try and commit some sooner rather than later you will eventually forget to commit something very important.

In short: Commit often and ALWAYS document the change. When there's a HUGE change, tag it.

blocks|key|1530794|text|不要仅仅为了背诵而承诺。我通常会为我正在处理的代码添加这些代码。例如，如果我正在修复方法A中的一个bug，那么我也要确保进行所有化妆品的更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1530795|你们缺少一些编码工具，如PMD、JIndent等，这些工具可以在编码时处理这些问题。有些IDE(如Netebean)将此“问题”显示为警告。因此，这不是一个随机的/个人的变化是遵循标准。|1530796|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Don't commit just for the sake of commiting. I usually add those for the code I'm working on. For example if I'm fixing a bug in method A I make sure to also make all cosmetic changes as well.

IMO you guys are missing coding tools like PMD, JIndent, etc that take care of this issues as you code. Some IDE's like Netebeans show this "issues" as warnings. So its not a random/personal change is following standards.

blocks|key|1562436|text|把他们和下一次重大的改变一起作为副业。至少我会这么做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1562437|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Commit them with the next big change as sidenote. At least that's what I'd do.

There are minor coding style changes that I often want to commit to the source control, but now the change log is full of those changes that do not affect code functionality.

What should I do next time I have to fix minor things like:

<ul>
<li>Remove and sort usings (in .NET, imports in python, includes in c++)</li>
<li>Correct indentation, spacing and line breaks</li>
</ul>

Should I commit cosmetic changes?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我经常希望提交到源代码管理的代码样式有一些小的更改，但是现在更改日志中满是那些不影响代码功能的更改。下一次我必须做些什么来解决一些小问题，比如：删除和排序用法(在.NET中，在python中导入，在c++中包括)正确的缩进、间距和换行()

问我应该做些化妆品的改变吗？
EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我应该做些化妆品的改变吗？EN

回答 12

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我应该做些化妆品的改变吗？
EN