作为一名 Git 新手，我意识到我一直在使用它，就好像它是 Subversion。例如始终在 master 上工作，而不是在拉取更改之前在本地提交等。这通常会导致可避免的手动合并情况。使用 Git 的其他常见反模式有哪些？
【问题讨论】：
标签： git version-control anti-patterns
当您编写提交消息时，您不知道在单行更改摘要中放置什么内容，这可能意味着您在单个提交中放置了太多独立的东西。最好使用“git rebase --interactive”和/或“git add --interactive”和朋友（如“git stash --keep-index”来测试隐藏的更改）将提交拆分成更小的内容。
在尝试使用“git bisect”查找错误时，每次提交只有一个问题将大有帮助。
【讨论】：
git gui 是一种简单 100 倍的方法。尽管我通常喜欢命令行，而且我用了很长时间，但我仍然使用 gui 进行基本提交，并使用 gitk 来可视化日志。
重新定位已经发布或合并的分支（然后重新发布该分支）。这样做会让每个人都讨厌你，因为这会导致可怕的问题，因为你刚刚重写了历史，并要求那些从你的 pre-rebase 分支合并的人手动修复你的 rebase 引入的问题。
详情另见http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebasing/。
【讨论】：
这比特定于 git 的更通用，但我见过许多带有提交消息的项目，例如“bugfix”或“fix foo”或“stuff”。不要那样做，而是使用有意义的提交消息，例如“component fiz: Fix foo bug[\n\nExtra info]”和“Whitespace cleanup”。当您稍后不可避免地查看您的提交历史时，您会感谢自己并且不需要说“当我提交'东西'时我到底是什么意思？”
【讨论】：
不使用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 commit --amend 或 git rebase -i 修复它。
作为一个在最近开始越来越多地使用 Git 之前经常使用 SVN 的人，我可以说我最糟糕的习惯是使用 git commit、git push、git commit、git push、git commit、@987654327 @...
换句话说，每次提交后总是推送，就像我还在使用 SVN。
在放弃该习惯所需的初始培训后，我的工作流程加载速度更快。 Git 的内置优点之一是本地提交比远程提交快得多。另一个好处是，不进行近乎恒定的远程提交可能不会让你日后失去信心（特别是如果它是一个小团队，即使它是一个大团队）。
对我来说，这是 SVN 中没有真正类比的地方（不会调用 Jakub Narębski's "big ball of changes" 反模式）。
【讨论】：
将一个大型存储库从 SVN 等迁移到一个大型 git 存储库是一种明确的反模式。 git 的设计方式，你不能做部分检出，甚至提交也会很慢。更好地模块化并为每个组件使用一个 repo。至少，每个团队的回购。绝对不是每个组织的回购。
【讨论】：