小規模なコミットを行う

バージョン管理に関しては、大規模なコミットではなく、小規模で集中的なコミットを多く行うことを推奨します。

そして私が生きている間、地球に小さな変化を加えていきます。
— 怯えたウサギ

ベストプラクティス: 小さな変更を積み重ねる

目標は、コミットを小さくすることだけではなく、焦点を絞った目的のあるものにすることです。各コミットは、コードベースに対する 1 つの論理的な変更を表す必要があります。

一日の終わりには、同じ変更に到達する可能性がありますが、小さなコミットは時間を管理し、将来に役立つ情報を残しながらタスクを正しく完了するのに役立ちます。

• 大規模なプロジェクトを小さなタスクに分割します。これは伝統的なプロジェクト管理スキルであり、時間を有効に活用し、成功した結果を生み出すために重要な部分です。パーキンソンの法則は、タスクは割り当てられた時間を埋めるまで拡大することを示唆しているため、より多くの小さなタスクを特定できると、時間の増加を抑えることができます。

• タスクがどのように説明的なコミット メッセージに変換されるかを考えてみましょう。タスクやメッセージが重複している場合、または類似している場合、それらのタスクをマージできますか?そうでない場合は、主な違いを特定して区別します。 プロのヒント: コミット メッセージに「および」という単語が表示される場合、または説明に複数の文が必要な場合は、コミットを分割する必要があります。

• コミットによってプロジェクトが動作状態のままになっていることを確認してください。常に可能というわけではありませんが、このガイドラインは、複数の開発者が 1 つのリポジトリで作業している場合に非常に役立ちます。プロジェクトを機能させたままにすると、ブランチの作成とマージがより頻繁になり、競合を制限できます。また、変更をロールバックする必要がある場合は、アプリケーションを機能したままにする可能性が高くなります。

• 確実に集中できるように、コミットする前に自分の変更を確認してください。時々、私たちはご都合主義的な変化に気づいたり、本来の任務を見失ったりすることがあります。これらの洞察や更新を失いたくない一方で、バージョン管理ツールや IDE の変更を分離してコミットを区別する方法は数多くあります。

一貫性

コミットの数が増えると、コミットを意味のあるものに保つことが難しくなることがあります。明確さと一貫性のために、従来のコミットのようなスタイルを採用することを検討してください。

利点

小さなコミットの利点は、いくつかの主要な領域で明らかになります。

コードレビューが容易になる

小規模で焦点を絞ったコミットは、理解と検証が容易です。レビュー担当者は、さまざまなコミットを個別に確認し、小さな作業単位ごとに関連する詳細に焦点を当てることができます。

コミットが小さいほど、レビュー担当者が疲労するリスクが減り、全体的な品質が高くなります。

プログラマに 10 行のコードをレビューするように依頼すると、10 個の問題が見つかります。彼に 500 行を描いてもらうと、彼はそれが良いと言うでしょう。
– ギライ・エジル

<script> // Detect dark theme var iframe = document.getElementById('tweet-306836785739210752-603'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=306836785739210752&theme=dark" } </script>

より良いデバッグ

コミットが小さいと、問題が発生した場所を特定しやすくなります。きめ細かいコミットを使用すると、git bisect などのツールをより効果的に使用して問題を特定できます。欠陥が特定されたら、小さなコミットを行うことで、既存のコードを変更するリスクとテスト範囲を制限することができます。

クリーナーの歴史

各コミットは、単一の変更についてのストーリーを伝える必要があります。コミットが小さい場合、そのストーリーはより明確になり、あなた自身を含む将来の開発者にとってより意味のあるものになります。

プロジェクトの年齢が上がるにつれて、コミット履歴から、選択されたパスと放棄されたパス、解決されたエラーと注意すべきリスクについて知ることができます。コミット メッセージがより適切で具体的であればあるほど、プロジェクト履歴を理解しやすくなります。

より安全なマージ

コミットが小さい場合、重複する変更によるマージ競合のリスクが低下するだけでなく、より小さな変更による競合の解決も容易になります。

より安全なロールバック

前に述べたように、何か問題が発生した場合、小さなコミットをロールバックする方が、相互に関連する大きな変更を元に戻すよりもリスクが低くなります。

リスクの低減

コミットされていないコードは、保存されていないドキュメントがあるようなものです。コード行が変更されてからチェックインされるまでに時間がかかるほど、その変更が失われる可能性が高くなります。誤って削除した場合。上書き;ブランチを切り替える前に変更を隠しておくことができませんでした。ファイルの代わりにブランチをリセットする...作業が失われる可能性がある方法はたくさんあります。

Git のような最新のバージョン管理では、ブランチは実質的に無料です。 git stash はいざというときに便利ですが、最終的に価値があるものになった場合に機能またはメンテナンス ブランチにマージできる一時ブランチを作成するのとほぼ同じ労力が必要です。

コミットされた変更はサーバー上のリポジトリのブランチまたはフォークにプッシュできるため、他のユーザーがそれらを表示して共同で作業できるようになり、ロケール システムが単一障害点になって作業にコストがかかることがないようになります。

スカッシュすべきですか?

フィーチャー ブランチで多数の小さなコミットを作成する場合、コード レビュー中に非常に役立つ個別の履歴を失わないよう、理想的にはプル リクエストを使用して、最後にこれらを 1 つのコミットにまとめることをお勧めします。

私は履歴を保存することを好みますが、マージの範囲と頻度によっても異なります。

物事ではなくテーマ

多くの場合、小さな変更をすべて最終的に表現する必要はありませんが、コミットが ライトモチーフ (単一の包括的なテーマ) を共有していない場合は、おそらく潰すべきではないでしょう。一緒に。

これは、Cleaner History の特典と関係があります。作業が行われている間、これらの個別のメッセージにより、コード レビューでの間違いや矛盾を簡単に発見できる可能性があります。

refactor: JIRA-12345 - Replace guards with optional chaining
refactor: JIRA-12354 - Replace logical OR with nullish coalescing 

作業が検証され、マージの準備が整うと、単一の潰されたコミットでそれらを表すことができます。

refactor: JIRA-12345 - ES2020 update

早めにスカッシュ、頻繁にスカッシュ

ブランチに多数のリファクタリング コミットが含まれている場合は、プロジェクトで追加の作業を行う前に、それらをマージして潰すことを検討してください。これにより、リファクタリングをプロジェクト作業から切り離しながら、より広範な履歴の中で単一のコミットとして表すことができます。

これにより、さまざまなタスクのリスクが個別の履歴エントリにさらに分離され、ブランチの寿命の短縮が促進されるため、

結論

このスタイルに慣れていない場合は慣れるまでに時間がかかるかもしれませんが、小さなコミットはコードの品質と開発プロセスの向上に役立ちます。

より小さなコミットを作成する練習をしてください。ほとんどすべてのバージョン管理と同様、今日の作業の成果は、将来的に自分自身と他の人に利益をもたらしますが、その日は予想よりも早く来る可能性があります。

以上が小規模なコミットを行うの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。