git - 変更をリポジトリにコミットするための適切な基準は何ですか?

Question

現在、いくつかのプロジェクトを管理するために git を使用していますが、最近 1 つの質問に悩まされています: マスターブランチとセカンダリブランチへの変更をコミットするための適切なトーンは何ですか? 「コンパイル時にコミットする」、「動作時にコミットする」、または何か他のものにする必要がありますか? ありがとう。

score 6 · Accepted Answer

第一に、転覆戦略とその考え方に由来する戦略を無視する。変更の保存と変更の公開には違いがあります。

コミットとは、変更を保存することです。タイマーでコミットすることはお勧めしませんが、バージョンをリリースするというよりも、ファイルを保存するようなものだと考えることをお勧めします。戻ってくる必要があるのではないかと恐れているが、そうしなければ元の場所に戻るのが難しいのではないかと心配しているときに行ってください。

ただし、公開する前にコミットを書き直してください (git rebase -i origin/master # など)。作成した混乱の意味を見つけ、適切なコミットメッセージを含む一連のわかりやすくクリーンなコミットを作成し、それぞれが行う品質チェックに合格するようにします。その後、公開します。

score 3 · Accepted Answer

これはあなたの個人的なレポですか、それとも多くの開発者によって共有されているレポですか? プロジェクトのどこまで進んでいますか?

個人的には、1 つのアスペクトが完了し、すべてがコンパイルされたら、Subversion リポジトリにコミットします。完全である必要はありませんが、壊れていないだけです。そもそも壊れたままにしない方がいいです。

半分書かれたコードはチェックインできますが、個人のブランチでのみチェックインできます。一般的に、その時点で何をしていたか、まだ何をする必要があるかについてのメモが付けられています。私は Subversion を使用しており、これは私の個人的なリポジトリであるため、主にこれを使用してデスクトップを離れ、ラップトップで中断したところから再開することができます。

一般に、コミットごとに 1 つのバグ/問題/機能があると便利ですが、開発スタイルに合わない場合があります。これがより完全なプロジェクトである場合、コミットはリストのどこかでアイテムをクロスしていることを意味し、もう 1 つのアイテムが完成したことを意味するため、うまくいく可能性があります。

他に考慮すべき点として、チェックインが必要な変更について重要なことは何ですか? たとえば、私は昨夜、内部 API を大幅に変更したコードをチェックインしました。これは、コミットメッセージとドキュメントの変更を文書化する必要があったことを意味します。同時に、タイプミスを修正するためにいくつかのコメントも変更しました。それはコミットメッセージに小さなサブノートを取得しますが、それ自体がコミットされるほど大きな問題ではないと私は考えています。

score 2 · Accepted Answer

いくつかの基本的なこと:

「論理的な変更」ごとにコミットするよう努めます。バグ修正、リファクタリング、機能、...
コードをコミットする前に単体テストを実行します。明らかなものを壊していないことを確認してください（ユニットテストはありますよね）。
マルチ開発者環境の場合。リポジトリから更新し、単体テストを再度実行して、競合する変更が誰かのコード (あなたのコードまたは彼らのコード) を壊していないことを確認します。
必要に応じて修正し、何も壊れなくなるまで 3 から繰り返します。
すぐにコミットして、指を交差させます。
継続的インテグレーションテストに頼って、他に問題がないかどうかを確認してください。

score 1 · Accepted Answer

チケット管理システムを使用している場合、タスクが修正されたらコミットします。

score 1 · Accepted Answer

私自身、「早期にコミットし、頻繁にコミットする」ことに同意します。自動化されたチェックアウトとビルドが進行中の場合、これは明らかに機能しません。

score 1 · Accepted Answer

一度に 1種類の変更のみをコミットします。

「タイプ」の意味はプロジェクトごとに異なりますが、一般的な例として、「外観の変更」と「機能の変更」、「リファクタリング」と「新規追加」などがあります。これにより、ログを見たときに変更を追跡しやすくなり、リビジョンに簡単に戻すこともできます。

score 0 · Accepted Answer

一歩下がって、短期間で完了できる問題/バグ/機能に取り組むようにしています。適切な停止ポイントに到達するまでに 1 日以上かかる場合は、タスクが大きすぎます。

とはいえ、ベストプラクティスは、コードがコンパイルされ、適切にテストされたときに変更をコミットすることだと思います (理想的には、コードの変更でコミットされる単体テストまたは統合テストを使用します)。

コンパイル + 適切に機能する + 十分にテストされている == 「動作したらコミットする」場合、それは適切なルールのようです。

score 0 · Accepted Answer

動作したらコミットします。私の場合、これは次のことを意味します:スモークテストを自動化し、実行してコミットします。

注: コミット前に自動化/実行するスモークテストです。回帰テストは継続的インテグレーションに任されています。

score 0 · Accepted Answer

0

二度と書きたくないコードをコミットしてください:)

于 2009-03-28T08:41:40.097 に答える

git - 変更をリポジトリにコミットするための適切な基準は何ですか?

9 に答える 9

Related

Reference