コミットプラクティスの改善について

私は自分のコミット方法を改善する方法を考えていました。

いいえとの間に相関関係はありますか？ソースコードの行となし。コミットの？

私が関わった最近のプロジェクトでは、1000行ごとに30回のコミットを行っていました。

プロジェクトの1つの典型的なファイルには、これらの統計があります

language: JavaScript
total commits that include this file: 32

total lines: 1408
source lines: 1140
comment lines: 98

no. of function declarations: 28
other declarations: 8

別のファイルにはこれらがあります...

Language: Python
total commits that include this file: 17

total lines: 933
source lines: 730
comment lines: 80

classes: 1
methods: 10

私もそうだと思います。コミットの数は、いいえに関連しています。機能の有無。コードへの変更の数は少なく、行の。

一般的なgitコミュニティのモットーは、短いコミットを作成し、頻繁にコミットすることです。

したがって、プロジェクトを開始する前に、戦略をコミットすることについて本当に考えていますか。それについて、コミット戦略のようなものはありますか？もしそうなら、あなたは何ですか？

DVCSを使用している場合は、非常に頻繁にコミットする必要があります。コードが安定した状態になるたびにコミットします。これはコード行とは関係ありません。多くの小さなアトミックコミットのツリーが必要です。これにより、それぞれの処理を簡単に確認できます。テスト時に見つかったリグレッションを追跡する場合、これにより、バイナリ検索を実行して正確なコミットを追跡することがはるかに簡単になります。コミットごとの変更が少なくなるからです。コードがコンパイルされたときにのみコミットします。「アトミック」の私の考えは、コードがコンパイルされ、回帰ユニットテストに合格し、迅速な統合テストに合格することです。単体テストが含まれる場合と含まれない場合があります。

プッシュするときは、機能全体をプッシュする必要があります。その他の国では、「このファイルでのチェックインの失敗」のコミットが毎日表示されることを望んでいません。Gitが提供するrebase。これにより、複数のコミットをまとめて押しつぶすことで、コミットツリーをクリーンアップできます。コミュニティは、どれだけの歴史をコミットすべきかについて不確かなようです。「失われたファイル」や「ダムの退行」のように、履歴をまったく表示しないコミットをまとめて潰す必要があると思います。誰もがあなたのしたことを簡単に見ることができるように、できるだけきれいな履歴を提示したいとします。

一元化されたバージョン管理システムでは、良い履歴を保持したい場合は、さらに多くのことをコミットする必要があります。私が推奨するのは、小さな機能に取り組み、コミットする前にできる限りそれらを完成させることです。ここでの「アトミック」の概念は、機能してテストされる機能でなければなりません。他の開発者のワークスペースを破壊するようなものはコミットしないでください。それらは頻繁に更新され、重複する独立した機能で作業することははるかに困難だからです。コミットは少なくなりますが、これらのコミットは通常、平均的なDVCSよりも多くなります。

コード行とコミット数の比率は、機能の大きさと使用するワークフローに依存することがわかります。使用するバージョン管理システムによってワークフローは異なるため、通常はコミットがどのようになるかを予測することはできません。各機関には独自の基準があり、ワークフローを理想的にどのようにするかを自分たちで決定する必要があります。

私は1 文字を変更するバグ修正のためにコミットしました。ここで、サイズは実際に決定的な要素ではありません。大体の目安は、意味のあるコミットメッセージを考えることができるときはいつでもコミットすることです。コミットをいつ共有するかは別の問題です。それはグループの文化によって異なりますが、一般的に、変更が意図したとおりに機能することを合理的に確信していることが必要です。

コミット数は行数に関連しているとは思いません。解決された問題/機能が導入される可能性が高くなります。私はこのかなり単純なアプローチ（git）を使用します。

• ローカルブランチに頻繁にコミットしますが、関連する何かが変更されたときのみ（不可解な問題が解決され、重要なファイル/関数がいくつか追加されました）。このようにして、特定の時間に作業していたものの最終的な解決策にたどり着いたステップ間を簡単に移動できます。
• リモート/パブリックリポジトリに送信するときに、ローカルコミットを単一の機能/問題関連のコミットにマージします。このように、あなたがしたことはすべて公開され、よく説明され、首尾一貫しているため、誰もがあなたのやっていたことを知っています（または少なくとも簡単なアイデアがあります）。

全体として、ローカルで行うことは何でもあなたのためです-あなたのために働くアプローチに固執してください。パブリックコミットについては十分に検討する必要がありますが、チームがすでに効果的なアプローチを取っている場合は、まったく新しい戦略を立てません。他の人との一貫性を保ちます。

後世のために、バグ/機能に関連するすべてのファイルを1つのリビジョンにコミットします。これは、後でバグを修正するためにどのファイルが変更されたかを知る必要があるときに、非常に役立ちます。

5つのコミット（ファイルごとに1つ）を追跡する代わりに、バグ＃783でチェックインされた5つのファイルを確認するために戻って何をしたかを簡単に確認できます。これは、チェックインをジョブ/バグ/機能/バックログ項目に一致させる、より優れたソース管理/ワークフロー統合がある場合に軽減できます。それでも頻繁にコミットしますが、関連するファイル/機能を毎回同じチェックインに入れます。

「すべてのコミットをビルド」するようにCIをセットアップしている場合、これはこれを行うのに役立ちます。