25

Git の初心者として、私は Git を Subversion のように使用していることに気付きました。たとえば、常にマスターで作業し、変更をプルする前にローカルでコミットしないなどです。これにより、回避可能な手動マージの状況が発生することがよくあります。Git の使用に関するその他の一般的なアンチパターンは何ですか?

4

6 に答える 6

20

変化の大きな球

コミット メッセージを書いていて、変更の 1 行の要約に何を入れたらよいかわからない場合、それはおそらく、1 つのコミットに独立したものを入れすぎていることを意味します。git rebase --interactive" " および/または " git add --interactive" とフレンド (" git stash --keep-index" のように、隠した変更をテストするため)を使用して、コミットを小さく分割することをお勧めします。

コミットごとに 1 つの問題があると、" " を使用してバグを見つけようとするときに非常に役立ちますgit bisect。

于 2009-09-29T18:39:58.110 に答える
9

すでに公開またはマージされているブランチのリベース (およびそのブランチの再公開)。そうすることで、歴史を書き直したばかりで、リベース前のブランチからマージした人々にリベースによって引き起こされた問題を手動で修正する必要があるため、ひどい問題が発生するため、誰もがあなたを嫌うでしょう。

詳細については、 http://hades.name/blog/2010/03/03/git-your-friend-not-foe-vol-4-rebaseing/も参照してください。

于 2010-11-02T14:10:26.550 に答える
8

これは git 固有というよりも一般的なものですが、「bugfix」、「fix foo」、「stuff」などのコミット メッセージを含む多くのプロジェクトを見てきました。代わりに、"component fiz: Fix foo bug[\n\nExtra info]" や "Whitespace cleanup" などの意味のあるコミット メッセージを使用してください。後でコミット履歴を必然的に見て、「「何か」をコミットしたとき、一体どういう意味だったの？」と言う必要がなくなったとき、あなたは自分自身に感謝するでしょう。

于 2010-07-14T03:07:44.317 に答える
7

使用していませんgit stash

シナリオ: あなたは機能 A に取り組んでいます。約 2 日かかり、完了するまでに約 1 日かかります。良いコードが書かれましたが、やるべきことはまだあります。上司が現れて、「今すぐ機能 B が必要です。10 秒かかります」と言います。

確かに - それを書くのに 10 秒、2 日間の作業が失われました。または、過去 2 日間に書いたすべてのコードをコメントアウトしてハックして、すべてを動作状態に戻すのに 2 時間かかりました。

git stashその日を救うためにここにいます。プロジェクトのルートでコマンド ラインに入力するだけgit stashで、最近の変更はすべて、変更のスタックである「スタッシュ」に格納されます。2 日前の状態に戻っていますが、作業は失われていません。10 秒間の変更を加えてチェックインし、入力git stash popして変更を元に戻します (そしてスタックから削除します)。

明らかなように、ひどい一日を過ごしている場合は、複数回 stash できますが、明らかにそうすればするほど、最終的にそれらすべてを git stash pop したときにマージの楽しみが減る可能性があります。数か月の作業で多くの隠し場所を蓄積できた場合はgit stash list、それらを調べて、持ち帰る価値のあるアイデアと捨てるのが最善のアイデアを選択し、git stash popひどいアイデアだけを隠しておく必要があります。git stash dropgit stash clear

于 2009-09-29T15:46:08.787 に答える
5

最近 Git をますます使い始める前に SVN をよく使っていた者として、私の最悪の習慣は , , , , ... を行うgit commitことgit pushだgit commitとgit push言えますgit commit。git push

つまり、私がまだSVNを使用しているように、コミットのたびに常にプッシュします。

その習慣をやめるために必要な最初のトレーニングの後、ワークフローの読み込みが速くなりました。Git の組み込みのメリットの 1 つは、ローカル コミットがリモート コミットよりもはるかに高速であるという事実です。もう 1 つのメリットは、ほぼ一定のリモート コミットを行わなくても、後で足を離すことはないということです (特に小さなチームの場合は、大きなチームであっても)。

私にとって、これは SVN に真の類推がないところです (それはJakub Narębski の「変化の大きなボール」アンチパターンを呼び起こしません)。

于 2010-07-14T03:30:29.560 に答える
3

1 つの大きなリポジトリを SVN などから 1 つの大きな git リポジトリに移行することは、明確なアンチ パターンです。git の設計方法では、部分的なチェックアウトを行うことはできず、コミットも遅くなる可能性があります。コンポーネントごとにレポをモジュール化して使用することをお勧めします。少なくとも、チームごとのレポ。組織ごとのリポジトリではありません。

于 2012-08-24T08:53:45.960 に答える