请勿使用GIt

2 年 ago

清, 扬

1 minute

引入

Git是一个非常方便的工具。但是，有一些类似于“做这个毫无意义吧”、“可惜了这么好的Git”、“反而妨碍了开发”的观点也存在。在这里，我们将介绍一些这样的“忌讳”集合的一部分。

情景1：不使用分支

コメント：トップバッターがいきなりアレですが、要はブランチを使いましょうということです。Gitの特徴としてマージが比較的容易であるという点が挙げられます。じゃんじゃんブランチを作り、マージしましょう。

情况二：分支名称中到处都是hoge或Bug fix。

コメント：ブランチを作るのはいいのですが、ブランチ名にも変数名と同じく気を遣いましょう（変数名、気をつけてますよね？）。当たり前ですが、同じ名前のブランチを複数作ることはできません。まあ、hogeなんていうブランチを作る人はさすがにいないと思いますが（いないよね？）、Bug fixやFix bug、Fixあたりをブランチ名にしてる人は気をつけてください。他の人も同じようにした場合、中央レポジトリ上で問題が発生する可能性が高いです。ブランチの内容をより詳細に説明するようなブランチ名にしましょう（例：fix_user_migration）。

案例3：对已推送的提交进行变基操作

コメント：これはやりがちです。Gitにおけるrebaseは、mergeと違ってコミットのハッシュ値を変更してしまいます。そのため、全く同じ内容のコミットが、プッシュ先とローカルで異なるものとみなされてしまうのです。その結果、一度プルしたにもかかわらず新規コミットが大量にあると思ったらハッシュ値が変わっただけだった、という事態が発生します。他の開発者は余計なマージを行わなくてはなりません。

案例4：向 master 分支进行强制推送。

コメント：git push –forceコマンドを使うと、リモートのコミットを上書きできます。トピックブランチの場合はそれでもいいのですが、前述の例のようにした場合、設定によっては全ブランチがフォースプッシュされます。たまたまその時、masterブランチを手元でgit commit –amendしていたら…さらに自動デプロイがされていたら…恐ろしいですね。Git2.0からはデフォルト設定が変更され、上記のようなことは起こりにくくなっていますが、それでも十分に気をつけましょう。

情境五：过多的合并提交

コメント：トピックブランチをつくったあと、本流のブランチとコンフリクトが発生してしまうことがあります。そうなるとrebaseかmergeをするのですが、すでに共有済みのブランチではrebaseはできないので（ケース３参照）、mergeをすることになります。マージコミットは通常のコミットと同様にlogに現れるので（一応git log –no-mergeで回避可能だが、GitHub等では回避不能）、あまりたくさんやると肝心のブランチの内容が見えづらくなることがあります。本流にマージする前に、トピックブランチのマージコミットをrebaseで削除してから（どうせマージしてから削除するので問題ない）最後に一つだけマージコミットを作成すると上手に決まります。そのためのrerereというツールもあります（詳しくはgit rerereで検索）。

总结

如果在场的人遇到了此处未提及但非常不寻常的Git使用方法，请在评论中告诉我，这里列举的只是不可忽视的一小部分。