我发现我对源代码做了很多小改动，通常是几乎没有功能影响的东西。例如：
我想我的代码中有一个对细节的强烈关注。但问题是我不知道如何处理这些变化，他们很难在git中的分支等之间切换。我发现自己不知道是否要进行微小的更改，隐藏它们，或者将它们放在一个单独的小调整分支中并在以后合并。这些选择似乎都不理想。
主要问题是这些变化是不可预测的。如果我要提交这些，就会有很多提交信息“Minor code aesthetic changes。”，因为，第二次我做了这样的提交，我注意到另一个类似的问题。当我做出一个小的改变，一个重大的改变，然后是另一个小的改变时，我该怎么办？我想将三个小改动合并为一个提交。当变化几乎不值得我注意时，在git status中看到文件被修改也很烦人。我知道git commit --amend，但我也知道这是不好的做法，因为它使我的回购与遥控器不一致。
答案 0 :(得分：16)
一方面，我认为中度频繁的微小变化不会对任何人或任何人造成太大伤害。我总是立即进行轻微的化妆品更改，在我们的团队中，我们同意在提交消息中使用化妆品一词，就是这样。
我不建议将化妆品与其他变化一起使用!!
另一方面，如果这对你来说是一个问题，你想改变一些我建议做化妆品会议的地方，你可以从你刚才提到的清单中修复所有类型的东西。仅在某个时间点专注于化妆品也可能更有效。否则，化妆品的变化可能会成为一种非营利性的活动。
答案 1 :(得分：7)
在git中，请记住，在推送（或以其他方式发布）提交之前，您可以根据需要自由编辑它们。在你的例子中，假设你还没有推动你的主要变化，我认为你完全有理由合并两个小的变化。如果你担心污染主代码库那么你可以做你的工作，照常提交，然后在推送之前，编辑提交以便将次要更改全部作为最近的提交，检查它是否足够大如果看起来太小，那就推动而不是推动那个提交。
答案 2 :(得分：4)
我认为你不应该将它们包含在其他“真正的”变化中。这样做会使合并分支时难以查看更改。
也许您将这些微小变化保留在自己的分支上的想法具有优点。
当我使用Perforce（带有多个更改列表）时，我可以将这些编辑保存在单独的更改列表中，直到我“足够”以保证签入。签入将包含多个文件，每个文件可能有多个布局更改但没有“真实”的变化。
答案 3 :(得分：4)
我认为您应该使用更好的提交消息单独提交这些更改。而不是'小代码审美变化'。你应该写一些诸如“在X视图的X部分中改变标题的间距”。
这不会以任何方式伤害你。
答案 4 :(得分：3)
你很幸运能使用git！正如其他人指出的那样，您可以在将更改推送到回购之前进行组合。这是git最酷的区别之一。如果你在一个分支上工作，我可以引导你：
> git checkout dev # branch for work
>> ... do some stuff
> git commit -am 'cosmetic only 1'
>> ... do some more stuff
> git commit -am 'cosmetic stuff I missed last time'
>> ... do some real stuff
> git commit -am 'real work'
> git checkout master && git pull && git checkout dev
# optional, if you repo is out of date
> git rebase --interactive master
此时，您可以重新安排提交，并将它们组合在一起 - 完全符合您的要求。最后：
> git checkout master && git merge dev && git push && git checkout dev
所以秘密是：
老实说，我一般不担心提交日志那么多。我只是深入研究历史，不足以使这种维护值得付出努力。
顺便说一句，如果你不在分支机构工作，我确信有办法做到这一点，但我不知道。以下是处理分支的参考：http://osteele.com/archives/2008/05/my-git-workflow
答案 5 :(得分：0)
我建议将它们分开并坚持下去，这样至少其他开发人员可以在没有太多恐惧的情况下合并它们。 :-)我倾向于做你所描述的。
另一个可行的建议是为代码定义标准化格式，并使用IDE或其他一些进程（build / checkin）在保存或签入时自动格式化代码。如果您是反叛者，您仍然可以在本地拥有自己的格式:-)但是在签入时所有代码看起来都是一样的。
我认为git能够定义pre-checkin钩子，但是还有ant目标，maven插件和IDE功能/插件，它们将以偏向的方式进行自动格式化。 / p>