管理git中的美学代码变化

Question

我发现我对源代码做了很多小改动,通常是几乎没有功能影响的东西.例如:

• 改进或更正评论.
• 在类中移动函数定义以获得更自然的阅读顺序.
• 间隔和排列一些声明以便于阅读.
• 使用多行将一些东西折叠到一个.
• 删除旧的注释掉的代码.
• 纠正一些不一致的空格.

我想我的代码中有一个对细节的强烈关注.但问题是我不知道如何处理这些变化,他们很难在git中的分支等之间切换.我发现自己不知道是否要进行微小的更改,隐藏它们,或者将它们放在一个单独的小调整分支中并在以后合并.这些选择似乎都不理想.

主要问题是这些变化是不可预测的.如果我要提交这些,就会有很多提交信息"Minor code aesthetic changes.",因为,第二次我做了这样的提交,我注意到另一个类似的问题.当我做出一个小的改变,一个重大的改变,然后是另一个小的改变时,我该怎么办？我想将三个小改动合并为一个提交.git status当变化几乎不值得我注意时,看到文件被修改也很烦人.我知道,git commit --amend但我也知道这是不好的做法,因为它使我的回购与遥控器不一致.

Answer 1

一方面,我认为中度频繁的微小变化不会对任何人或任何人造成太大伤害.我总是立即进行轻微的化妆品更改,在我们的团队中,我们同意在提交消息中使用化妆品一词,就是这样.

我不建议将化妆品与其他变化一起使用!!

另一方面,如果这对你来说是一个问题,你想改变一些我建议做化妆品会议的地方,你可以从你刚才提到的清单中修复所有类型的东西.仅在某个时间点专注于化妆品也可能更有效.否则,化妆品的变化可能会成为一种非营利性的活动.

Answer 2

在git中,请记住,在推送(或以其他方式发布)提交之前,您可以根据需要自由编辑它们.在你的例子中,假设你还没有推动你的主要变化,我认为你完全有理由合并两个小的变化.如果你担心污染主代码库那么你可以做你的工作,照常提交,然后在推送之前,编辑提交以便将次要更改全部作为最近的提交,检查它是否足够大被推,如果它看起来太小,就不推动那个提交.

Answer 3

我认为您不应该将它们与其他“真正”的更改一起包含在内。这样做会使合并分支时审查更改变得困难。

也许您将这些微小的更改保留在自己的分支上的想法有其优点。

当我使用 Perforce（具有多个更改列表）时，我可以将这些编辑保留在单独的更改列表中，直到我“足够”保证签入。签入将包含多个文件，每个文件可以有多个布局更改，但没有“真正的”变化。

Answer 4

我认为您应该使用更好的提交消息单独提交这些更改.而不是'小代码审美变化'.你应该写一些诸如'在X视图的X部分中改变标题的间距'之类的东西.

这不会以任何方式伤害到你.