使用 Git 的常见反模式是啥？ [关闭]

Posted 2023-05-07

【中文标题】使用 Git 的常见反模式是啥？ [关闭]

【英文标题】：What are common antipatterns of using Git? [closed]使用 Git 的常见反模式是什么？ [关闭]

【发布时间】：2010-12-02 06:46:54

【问题描述】：

作为一名 Git 新手，我意识到我一直在使用它，就好像它是 Subversion。例如始终在 master 上工作，而不是在拉取更改之前在本地提交等。这通常会导致可避免的手动合并情况。使用 Git 的其他常见反模式有哪些？

【问题讨论】：

我感觉这个问题应该是社区维基。还是您真的打算接受其中一个答案？

那你为什么不把它做成社区维基呢？

相关：basilv.com/psd/blog/2009/…

【参考方案1】：

大变化

当您编写提交消息时，您不知道在单行更改摘要中放置什么内容，这可能意味着您在单个提交中放置了太多独立的东西。最好使用“git rebase --interactive”和/或“git add --interactive”和朋友（如“git stash --keep-index”来测试隐藏的更改）将提交拆分成更小的内容。

在尝试使用“git bisect”查找错误时，每次提交只有一个问题将大有帮助。

【讨论】：

也将“git gui”作为“git add --interactive”的 GUI。您可以直观地选择大块和代码行。

git gui 是一种简单 100 倍的方法。尽管我通常喜欢命令行，而且我用了很长时间，但我仍然使用 gui 进行基本提交，并使用 gitk 来可视化日志。

您可以添加多行 git 提交消息。如果您想从命令行执行此操作，请使用 git commit -m "

之类的引号打开

【参考方案2】：

重新定位已经发布或合并的分支（然后重新发布该分支）。这样做会让每个人都讨厌你，因为这会导致可怕的问题，因为你刚刚重写了历史，并要求那些从你的 pre-rebase 分支合并的人手动修复你的 rebase 引入的问题。

详情另见http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebasing/。

【参考方案3】：

这比特定于 git 的更通用，但我见过许多带有提交消息的项目，例如“bugfix”或“fix foo”或“stuff”。不要那样做，而是使用有意义的提交消息，例如“component fiz: Fix foo bug[\n\nExtra info]”和“Whitespace cleanup”。当您稍后不可避免地查看您的提交历史时，您会感谢自己并且不需要说“当我提交'东西'时我到底是什么意思？”

【参考方案4】：

不使用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 pop 和git stash drop 来挑选哪些值得带回来，哪些最好扔掉，以及@ 987654329@，如果你只隐藏糟糕的想法。

【讨论】：

当然不使用 git stash。

这与创建分支相反。像 svn 这样的典型 sc 提供程序会让您创建一个对存储库中的每个人都可见的新分支。在一个广泛使用的存储库中，这可能是不受欢迎和破坏性的，现在你必须想一个好的清晰的分支名称......。然后签入，切换回主干，最后你的 10 秒修复可以开始了。所有这些，或者只是 git stash。

git stashes 可能会丢失。分支更加稳定和可见。当你有一个分支时，你可以多次提交，而不是依赖一个 blob 作为你两天的工作，因为真的，你不应该在没有任何提交的情况下工作 2 天。

git stash 特别适用于您可能只是继续隐藏在新分支上的工作。但我会考虑积累几个月的存储空间本身就是一种反模式。就像在不提供名称/cmets 的情况下进行存储一样 - 以防万一你不回到它​​。

在这种情况下，我会在 2 天开始时创建一个新的本地分支。 2 天的工作将代表该分支上的大量提交。我有时会使用 [临时提交] 之类的日志消息进行提交，而不是隐藏，我知道我可以稍后使用 git commit --amend 或 git rebase -i 修复它。

【参考方案5】：

作为一个在最近开始越来越多地使用 Git 之前经常使用 SVN 的人，我可以说我最糟糕的习惯是使用 git commit、git push、git commit、git push、git commit、@987654327 @...

换句话说，每次提交后总是推送，就像我还在使用 SVN。

在放弃该习惯所需的初始培训后，我的工作流程加载速度更快。 Git 的内置优点之一是本地提交比远程提交快得多。另一个好处是，不进行近乎恒定的远程提交可能不会让你日后失去信心（特别是如果它是一个小团队，即使它是一个大团队）。

对我来说，这是 SVN 中没有真正类比的地方（不会调用 Jakub Narębski's "big ball of changes" 反模式）。

【参考方案6】：

将一个大型存储库从 SVN 等迁移到一个大型 git 存储库是一种明确的反模式。 git 的设计方式，你不能做部分检出，甚至提交也会很慢。更好地模块化并为每个组件使用一个 repo。至少，每个团队的回购。绝对不是每个组织的回购。

【讨论】：

+1 对此，虽然我会关注 Git 子模块为 Component engineering 提供内置支持这一事实，而不是关注大型存储库可能存在的 Git 限制（我没有经历过你提到）。