svn から git に切り替えてから、再コンパイルしてテストに合格するたびに、より多くのコミットを開始し、作業をコミットしました。最後に、関数ごとに関数をコミットすることになります。
また、emacs、wordpress などの git を使用する他のプロジェクトも追跡しています。それで、どのくらいの頻度でコミットしますか？
13241 次
11 に答える
64
Git プロジェクト自体 (および Linux プロジェクト、AFAIK) のガイドラインは、「論理的に分離された変更セット」ごとに 1 つのコミットです。
これは少しあいまいですが、プロジェクトで常に作業している場合は、おそらく数日ごとにコミットしたくないでしょう。また、関数の変更ごとにコミットしたくないでしょう。いくつかの異なるファイルがある場合は、関連するすべての機能をまとめてコミットし、有用なコミット メッセージを提供する必要があります。各コミットで変更されたすべてのコードは関連している必要がありますが、複数のファイルにまたがっている可能性があります (おそらく関連しているはずです)。
おそらく心に留めておきたいのは、コードレビューです。誰かがあなたの作業をマージするかどうかを決定しようとしている場合、各コミットが論理的に含まれ、互いに分離されていると、導入された作業を処理するのがはるかに簡単になります。これにより、あなた（または他の人）はチェリーピックを効果的に機能させることができます-それぞれに1つの関数が変更された3つのコミットがあり、それらがすべて何らかの形で結合されている場合-コードベースを壊さずに他の2つなしで1つを適用することはできません-その後、おそらくすべきです1 つのコミットに押しつぶされます。
于 2009-06-25T03:29:12.810 に答える
26
また、emacs、wordpress などの git を使用する他のプロジェクトも追跡しています。
git の優れた点の 1 つは、好きなだけコミットできることです。アップストリーム コミットを実行したい場合は、git-rebase.
于 2009-06-24T17:42:05.370 に答える
14
結局、私は関数ごとに関数をコミットすることになります
git add関数ごとに「」、コミットを1つだけ行うことができることを忘れないでください。
- 特定のタスクに対してすべての関数が記述または修正されたら
- または、現在の関数が大きすぎて複雑すぎてすぐにコミットに参加できないことに気付いたら、現在「ステージ上」にあるもの（「gitadded」）をコミットできます。これには、現在の変更が作業に含まれません。ディレクトリ。
次に、コミットの数をブランチの目的に関連付けることができます。
- ローカルブランチ：夢中になり、いつでもコミットできます
- 「パブリック」ブランチ（プッシュするブランチ）：
- ローカルリポジトリの場合（選択したグループの人々の場合）：少なくとも非常に小さな「中間」コミットを再グループ化できます
- パブリックリポジトリの場合（すべての開発者または他のプロジェクトが表示できるように）：コミットを「アクティビティ」または「タスク」で再グループ化して読みやすくするために、インタラクティブなリベースを作成できます。
要するに、「公開の考慮事項」は、D VCS（「分散」の場合のように）で、適切な理由で適切な数のコミットを行うようにガイドすることができます。
于 2009-06-24T19:38:12.870 に答える
10
コミットすればするほど、 git bisectでバグを見つけやすくなります
于 2009-06-25T03:50:47.203 に答える
7
テストに合格した直後、または機能のユニットが追加/削除/変更されたとき。
于 2009-06-24T17:41:04.217 に答える
3
私たちのビジネス ニーズでは、プログラムのコンパイル時に不安定ブランチにコミットし、ユニット テストに合格して顧客によるレビューが完了したときに (不安定ブランチの下にあったときに) 安定ブランチにコミットする必要があります。
于 2009-06-24T17:44:57.707 に答える
3
それは本当に依存します。
私がしていることは、あなたがしているように聞こえるように、頻繁にローカルにコミットすることですが、いくつかの影響力のある変更が発生した場合にのみ、変更をプッシュします。
これにより、自分の作業を確実に保存できますが、他のユーザーのリポジトリが乱雑になることもありません。
于 2009-06-24T17:42:22.263 に答える
2
機能を追加または変更し、テストが成功した後にコミットします。または、デスクトップからラップトップに切り替えてコードをプルダウンしたい場合は、コミットしてプッシュします。
于 2013-05-27T12:40:58.677 に答える
1
あなたがしていることは、私には正しいように聞こえます。何かを台無しにした場合に戻ることができるようにしたい作業セットアップがあるときはいつでも、コミットするのに良い時期です. 回帰テストをすばやく簡単に実行できる適切な設定があれば、それはかなり頻繁に行われることがわかります。私にとっては、週に1つ作ることができて幸運です.
于 2009-06-24T17:55:30.077 に答える
0
1-コミットは頻繁にする必要があります。コードが失われた場合に備えてコードをバックアップできるように、(ローカルだけでなく) リモート リポジトリにコードをコミットすることを頻繁に行う必要があります。これは予想以上に頻繁に発生するため、やり直しの可能性を回避し、リモート リポジトリを常に最新の状態に保つために、1 日の終わりまでに変更をプッシュする必要があります。
2- コミットは細かくする必要があるため、コード ベースにあまり多くの変更を含めないでください。変更が多すぎるコミットは元に戻すのが難しく、スコープ全体をカバーするにはコミット メッセージが長すぎるため、「履歴」の観点から参照として使用することはできません。
3- コミットには適切なタイトルが必要です。タイトルは大文字で始まり、ピリオドで終わってはいけません。一般的に、タイトルは短く要点を示す必要があります。
4- コミットの説明はオプションですが、あると便利です。
于 2019-03-21T13:12:40.463 に答える
-5
私はかなり離れてコミットします。git はコードを「バックアップ」するためのものではありません。コードを失わないように、tarball や dropbox などを使用する必要があります。
あまり頻繁にコミットしない場合は、どのコミットに何を入れるべきかを正確に伝えることができ、50 のコミットよりもスムーズな履歴が得られます。
「おっと」、「いまいましい」、「そのファイルを忘れた」
リベースできますが、そもそもステージング/コミットしない場合は、作業を元に戻す必要はありません
于 2011-07-29T09:50:12.283 に答える