在git中管理审美代码更改

我发现我对源代码做了很多小的更改，通常情况下几乎没有任何功能影响。例如：在git中管理审美代码更改

提炼或更正评论。
在一个类中移动函数定义以获得更自然的阅读顺序。
间距和排列一些声明的可读性。
折叠使用多行到一个的东西。
删除旧的注释代码。
纠正一些不一致的空白。

我想我有一个强大的关注我的代码中的细节。但问题是我不知道如何处理这些变化，并且它们使得在git中的分支之间切换变得困难。我发现自己不知道是否要进行微小的改动，把它们藏起来，或者把它们放在一个单独的小调整分支中，并在稍后进行合并。这些选项似乎都不理想。

主要问题是这些变化是不可预测的。如果我要这样做，那么会有很多提交“Minor code aesthetic change”的提交，因为第二个我做出这样的提交，我注意到另一个类似的问题。当我做一个小小的改变，一个重大的改变，然后另一个小的改变时，我应该怎么做？我想将三个小改动合并为一个提交。当更改几乎不需要我的注意时，看到在git status中修改的文件也很烦人。我知道git commit --amend，但我也知道这是不好的做法，因为它使我的回购与遥控器不一致。

来源

2009-09-24 Ollie Saunders

这是所有源控制系统共有的问题。我还没有遇到系统内置的答案。 – ChrisF 2009-09-24 11:34:14

如果您保留的地方分支永远不会推送/提交补丁（例如整型分支），那么诸如'commit --amend'和'rebase -interactive'（可以重新排序，编辑和压缩提交）突然有可能良好的做法 - 他们可以使您的发展历史更清洁！ – Cascabel 2009-09-24 12:30:48

使用MQ Extension for mercurial在mercurial中获得git rebase功能 – 2009-09-27 06:26:48

一方面我不认为适度频繁的微小变化会对任何事物或任何人造成很大的伤害。我总是在我们的团队中立即做出轻微的美容修改，我们已经同意我们只在我们的提交信息中使用化妆品这个词，就是这样。

我不会推荐的是将化妆品与其他变化一起！另一方面，如果这对你来说是一个问题，你想改变一些东西，我会建议你做一个美容会议，你可以从你提到的列表中解决所有类型的问题。仅在特定时间点专注于化妆品也可能更有效。否则美化变化可能会成为拖延式活动。

来源

2009-09-24 11:51:39 markus

我不认为你应该包括他们与其他“真正”的变化。这样做会使合并分支时难以查看更改。

也许你在自己的分支上保留这些细微变化的想法有其优点。

当我使用Perforce公司（与它的多个变更表），我可以把这些编辑在一个单独的变更表，直到我有“足够”，在保证一个校验，校验中会包含多个文件和每个文件可以有多个布局但没有“真实”的变化。

来源

2009-09-24 11:37:07 ChrisF

git中的模拟是保留一个整型分支，并且可能交互地重新绑定它以在合并之前将它们很好地压合在一起，或者保留化妆品存储，定期应用它，添加更多的变化，并再次存储它。不幸的是，由于外观变化经常会影响很多线条，因此您会开始较快地遇到合并冲突。 – Cascabel 2009-09-24 12:29:05

我想你应该用更好的提交信息分别提交这些更改。而不是“小代码美学改变”。你应该写一些东西，比如'在X视图的X部分中改变头部的间距'。

这不会以任何方式伤害你。

来源

2009-09-24 12:11:23 allesklar

在git中，请记住，除非您推送（或以其他方式发布）提交，否则您可以根据需要自由编辑它们。在你的例子中，假设你还没有推动你的主要变化，我认为你合并这两个小变化是完全合理的。如果您担心污染主代码库，那么您可以像往常一样执行您的工作，然后在推送前编辑提交，以便将最小的更改合并为最近的提交，检查它是否足够大如果它看起来太小，就不推动那个提交（还）。

来源

2009-09-24 12:20:07

你可以使用“git rebase -i ”来重新排序和压缩美学变化到单个提交中：http：// www。kernel.org/pub/software/scm/git/docs/git-rebase.html#_interactive_mode – 2009-09-24 12:53:38

我建议让他们分开并坚持，以便至少其他开发人员能够合并他们而不用担心太多。 :-)我倾向于做你所描述的。

另一个可行的建议是为代码定义标准化的格式，并使用IDE或其他进程（build/checkin）在保存或签入时自动格式化代码。因此，如果您是反叛者，那么您仍然可以在本地使用自己的格式:-)但是当签入时，所有代码看起来都是相同的。

我认为git能够定义预检入钩子，但也有蚂蚁目标，maven插件和IDE功能/插件，可以以自动方式进行自动格式化。

来源

2009-09-24 16:04:34 cjstehno

你很幸运能够使用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

在这一点上，你可以重新安排你的提交，并结合他们together--正是你想要的。于是最后：

> git checkout master && git merge dev && git push && git checkout dev

所以秘密是：

Git的轻松的一个分支工作能力
检查往往
Git的在系统中已经编辑提交能力的Git的便利

说实话，我一般不担心提交日志那么多。我只是深入挖掘历史，足以让这种维护工作值得努力。

顺便说一句如果你不在分支上工作，我确信有一种方法可以做到这一点，但我不知道它。以下是关于在分支上工作的参考：http://osteele.com/archives/2008/05/my-git-workflow

来源

2009-09-26 02:14:23 ndp

在git中管理审美代码更改

回答

相关问题