使用Git时常见的反模式是什么?

25
作为一个Git的新手,我意识到我一直像使用Subversion一样使用它。例如,总是在主分支上工作,在拉取更改之前不进行本地提交等等。这经常导致可避免的手动合并情况。还有哪些常见的Git反模式?

1
我有一种感觉,这个问题应该是社区维基的。或者你真的打算接受其中一个答案吗? - innaM
那你为什么不把它变成社区维基呢? - innaM
相关链接:http://www.basilv.com/psd/blog/2009/the-five-commandments-of-version-control - Jakub Narębski
6个回答

20

大量变更

当你在编写提交信息时不知道要在单行总结中放置什么内容时,这可能意味着你将太多独立的事情放入了一个提交中。最好使用“git rebase --interactive”、“git add --interactive”等命令拆分提交,或者使用类似于“git stash --keep-index”来测试暂存的更改。

每个提交只包含单一问题会在使用“git bisect”查找错误时非常有帮助。


2
还有一个名为“git gui”的GUI,用于“git add --interactive”。您可以通过可视化方式选择代码块和代码行。 - Vi.
“git gui” 是一个更加简单易用的方式。虽然我通常喜欢使用命令行,而且长时间以来都只使用命令行,但是对于基本的提交,我仍然使用 GUI,并使用 gitk 来可视化日志。 - rjmunro
你可以添加多行的 Git 提交信息。如果你想要在命令行中这样做,需要用引号打开,例如 git commit -m "。 - Chris McCowan

9

这个建议不只是针对git,更是通用的。我看过很多项目都有像“bugfix”、“fix foo”或者“stuff”这样的提交信息。不要这样做,而是使用有意义的提交信息,例如“组件fiz: 修复foo bug[\n\n额外信息]”和“清理空格”。当你无可避免地回顾提交历史时,你会感谢自己没有写“stuff”,因为你不需要问自己:“我提交‘stuff’时到底是什么意思?”


8
重新定位一个已经发布或合并的分支(然后重新发布该分支),这样做会让所有人都讨厌你,因为它会导致可怕的问题,由于你刚刚重写了历史,需要那些从你的预重新定位分支合并过来的人手动修复由你重新定位引入的问题。
另请参见http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebasing/获取详细信息。

7

不使用git stash

场景:您正在开发功能A,已经花费了大约2天的时间,距离完成还有一天的时间。您已经写了良好的代码,但还有更多工作要做。您的老板出现并说:“嘿,我现在需要功能B。应该只需要10秒钟。”

当然-10秒钟就可以写完,但是失去了2天的工作。或者花费2个小时来注释和修改过去2天编写的所有代码,以使一切恢复到工作状态。

git stash来拯救你。只需在项目的根目录下,在命令行中键入git stash,您最近的更改将进入“stash”,即更改堆栈。现在您回到了2天前的状态,但您的工作没有丢失。您进行10秒钟的更改,检查后,然后键入git stash pop以获取您的更改(并从堆栈中删除它们)。

显而易见,如果你有糟糕的一天,你可以多次隐藏,尽管显然,你这样做的次数越多,当你最终git stash pop所有内容时,合并将变得不那么有趣。如果你在几个月的工作中累积了很多隐藏内容,你可以使用git stash list查看它们,使用git stash popgit stash drop挑选出哪些值得带回来,哪些最好直接丢弃,并使用git stash clear只隐藏可怕的想法。


2
当然不使用 git stash。 - innaM
5
这与创建分支相反。像 svn 这样的典型源代码管理工具会要求你创建一个新分支,并让所有人都能在代码库中看到它。在广泛使用的代码库中,这可能会引起不必要的干扰和混乱,而且你还需要考虑一个好的清晰的分支名称...。接着进行检查,切换回主干,最后才能开始你的 10 秒钟修改。而你只需使用 git stash 命令即可完成以上所有步骤。 - Chris Moschini
4
Git的"暂存区"可能会丢失。相比之下,分支更加稳定和可见。当你使用分支时,可以多次提交修改,而不是依赖一个单独的文件保存两天的工作内容,因为实际上,你不应该在没有任何提交记录的情况下连续工作两天。 - Kzqai
2
git stash 特别适用于当您可能只是在新分支上继续暂存的工作时。但我认为,积累数月的暂存本身就是一个反模式。如果没有给暂存命名/注释,那么将其暂存起来是不恰当的——以防万一您无法返回它。 - Bob Kerns
1
在这种情况下,我会在2天开始时创建一个新的本地分支。而且2天的工作将代表该分支上的许多提交。有时候我不使用stash,而是使用类似于[临时提交]的日志消息进行提交,因为我知道稍后可以使用git commit --amendgit rebase -i来修复它。 - rjmunro
显示剩余3条评论

5
作为一个之前经常使用SVN,最近开始越来越多地使用Git的人,我可以说我的最坏习惯就是做git commitgit pushgit commitgit pushgit commitgit push...... 换句话说,每次提交后都要推送,就像我仍在使用SVN一样。
在摆脱这个习惯所需的初始培训之后,我的工作流程变得更快了。Git内置的好处之一是本地提交比远程提交快得多。另一个好处是,如果不经常进行远程提交,可能不会影响以后的工作(特别是对于小团队,即使是大团队也是如此)。
对我来说,在SVN中没有真正的类比(这不会引起Jakub Narębski的“大变更球”反模式)。

3

将一个大型代码库从SVN等迁移至一个大型git仓库是一个明显的反模式。由于git的设计,你不能进行部分检出,甚至提交也可能会很慢。最好将其模块化并使用每个组件一个仓库的方式。至少,每个团队一个仓库。绝不是每个组织一个仓库。


我支持这个说法,不过我想重点强调的是Git子模块提供了内置的支持 组件工程,而不是可能存在的Git在大型代码库方面的限制(我没有遇到你提到的那些情况)。 - André Caron

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接