Gitは柔軟な分岐戦略を提供しますが、それはどういう意味ですか？簡単に言うと、分岐戦略は一連のルールであり、チームと開発者を支援する規則です。これらの規則と規則に従って、新しいブランチやそのフローなどを作成できます。
適切な命名規則を使用しないと、混乱が生じ、コード保守チームが複雑になります。命名規則を分岐する際のGitのベストプラクティスを無視することはできません。
Git分岐戦略により、作業を分離できます。大まかに言って、Gitブランチは通常ブランチと一時ブランチの2つのカテゴリに分類できます。
通常のGitブランチ
これらのブランチは、永続的にリポジトリで利用できるようになります。それらの命名規則は単純でわかりやすいものです。
- 開発（ dev ）は主要な開発ブランチです。 devブランチのアイデアは、それに変更を加え、開発者がmasterブランチに直接変更を加えることを制限することです。 devブランチでの変更はレビューを受け、テスト後、masterブランチとマージされます。
- マスター（マスター ）は、Gitリポジトリで使用可能なデフォルトのブランチです。常に安定している必要があり、直接チェックインすることはできません。コードレビュー後にのみマージできます。すべてのチームメンバーは、マスターを安定して最新の状態に保つ責任があります。
- QA（ QA ）、またはテストブランチには、実装されたすべての変更のQAテストおよび自動化テストのすべてのコードが含まれています。変更を本番環境に移す前に、安定したコードベースを取得するためにQAテストを受ける必要があります。
一時的なGitブランチ
名前が示すように、これらは必要に応じて作成および削除できるブランチです。次のようになります。
- バグ修正
- ホットフィックス
- 機能ブランチ
- 実験的なブランチ
- WIPブランチ
一時的なブランチについて専門家が推奨する多くの形式と命名規則があります。
これがGitブランチの簡単なワークフローです。
Git Branching Naming Convention
この記事では、効率を確保するために過去に個人的に使用した7つの最良の命名規則を確認して共有します。
1。グループワードでブランチ名を開始します
これはベストプラクティスの1つです。グループワードは、ワークフローに一致するものであれば何でもかまいません。
私は次のような短い言葉が好きです：
バグ –すぐに修正する必要があるバグ
WIP –作業は進行中であり、すぐには終了しないことを認識しています
ブランチ名を見ると、このGitブランチの内容とその目的を理解できます。
以下の例をご覧ください：
- bug-logo-alignment-issue –開発者はロゴの配置の問題を修正しようとしています。
- wip-ioc-container-added –ブランチは、進行中のIoCコンテナを追加するタスクに関連しています。
2。ブランチ名に一意のIDを使用する
ブランチ名に課題追跡IDを使用できます。いくつかのバグの修正に取り組むときは、この方法を好みます。例：
wip-8712-add-testing-module
この名前は、ブランチがテストモジュールを追加するタスクに適用され、問題の追跡IDが8712であり、作業が進行中であることを示しています。
ブランチ名に外部追跡IDを使用するもう1つの利点は、外部システムからの進行状況を追跡できることです。
3。区切り文字としてハイフンまたはスラッシュを使用する
多くの開発者は区切り文字としてスラッシュを使用し、多くはハイフンを使用します。どちらを使用するか–あなたとあなたのチームの好みによって異なります。
私の意見では、ハイフンを使用すると名前が読みやすくなるため、ブランチ名の区切り文字として適しています。スラッシュ、ハイフン、およびアンダースコアを使用できます。重要なのは一貫性を保つことです。
ブランチ名にセパレータを使用する主な利点は2つあります。
- 読みやすさが向上し、混乱を避けるのに役立ちます。
- 特に多くのブランチを扱っている場合は、管理が容易になります。
例1.区切り文字なしのGitブランチ名：
featureupgradejqueryversionloginmodule
例2.セパレーター（この場合はアンダースコア）を追加することで、Gitブランチ名を読みやすくします：
feature_upgrade_jquery_version_login_module
4。著者名のGitブランチ
多くの企業は、以下の形式に従って、著者の名前をブランチ名に追加することを好みます。
<author>_<branch-type>_<branch-name>例： rajeev.bera_feature_new-experimental-changes
この方法では、さまざまな開発者の作業と追加のシステムの進捗状況を簡単に追跡できます。
5。数字のみの使用は避けてください
一部の開発者は、ブランチ名に問題IDのみを使用しますが、これは作業の進行には役立ちません。
たとえば、ブランチ名9912があります-この魔法の番号は私たちに何を教えてくれるでしょうか？これは、特に他のgitブランチとのマージ中に、より多くの混乱とミスのリスクを意味するだけです。
6。すべての命名規則を同時に使用することは避けてください
すべてのGitブランチの命名規則を組み合わせて一致させることは、ベストプラクティスではありません。混乱を招き、プロセス全体を複雑にするだけです。
チームは、作業で使用する命名規則を一度決定し、それらに固執する必要があります。一貫性が最も重要です。
7。寿命の長いブランチの長い説明的な名前は避けてください
ブランチ名の本質的な品質は、正確で有益なものでなければならないということです。いくつかの例をもう一度見てみましょう：
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
そこでは、ブランチ名が長く詳細になっています。それは必要ない。代わりに、次のバリアントを使用できます：
wip_feature_login_module
この名前は短いですが、このブランチの目的を説明しています。
結論
Gitブランチモデルは強力ですが、ブランチを正しく効果的に管理する必要があります。必要な要素の1つは、すべてのチームによる同じ規則、特にローカルリポジトリの命名規則に従うことです。
チームが合意された規則を使用していることを確認するには、標準を適用します。最も簡単な方法の1つは、pre-commitフックのようなGitフックを使用することです。 Gitの分岐モデルとその命名規則についてのアイデアが得られることを願っています。