I. はじめにGitは優れたバージョン管理ツールであり、そのブランチ管理機能により、チームによる共同開発を驚くほど容易にします。この記事では、製品開発におけるGitのブランチ管理手法について解説します。 II. 製品ソフトウェアバージョン番号の定義ソフトウェアのバージョン番号は、メジャーバージョン番号、マイナーバージョン番号、リビジョン番号、ビルド番号の4つの部分で定義されます（例：V1.3.2.123）。ソフトウェアのホットフィックスのバージョン番号も、メジャーバージョン番号、マイナーバージョン番号、リビジョン番号、パッチ番号の4つの部分で定義されます（例：V1.3.2.125）。 バージョン番号 | 説明する | 述べる | メジャーバージョン番号 | システム業務またはアーキテクチャが再構築された場合に追加します。機能または方向性に大きな変更があった場合に追加します。以前のインターフェースとの互換性が広範囲に及ばない場合に追加します。 |
| サブバージョン番号 | 新しいビジネス機能を追加するときに追加します。 |
| リビジョン番号 | 必要に応じて追加します。 | 0から始める | 修理番号 | Hostfixのバージョン番号は、パッチ適用対象バージョンのビルド番号に基づいており、リリースの最高ビルド番号から増加します。例えば、パッチがV1.3.2.1に基づいている場合、ホットフィックスのバージョンはV1.3.2.2になります。現在のリリースのビルド番号がV1.3.2.101で、現在の最高ビルド番号が105の場合、パッチのバージョン番号はV1.3.2.106になります。 | 1から始まる | ビルド番号 | コンパイル番号は、コンパイルが行われるたびに増加します。 | 1から始まる |
III. Git ブランチの命名1. 基本的な枝ブランチ名 | 説明する | ライフサイクル | マスター | このブランチにはリリースされたバージョンの反復が記録されます。このブランチのコードは製品コードと完全に同一です。 | プロジェクトは存続期間中は存在し、廃止された後はアーカイブされます。 | 開発 | 開発コードアクティビティの履歴を記録する | マスターと同じ | テスト | テストアクティビティ履歴を記録する | マスターと同じ | 機能-(バージョン)-(名前) | このブランチは、個々の開発者のコードアクティビティ履歴を表します。例えば、Davidがバージョン1.0.1を開発している場合、ブランチ名はfeature-v1.0.1-davidとなります。 | 開発開始からリリースまで、そしてリリースから完了まで。 |
2. 拡張ブランチブランチ名 | 説明する | ライフサイクル | ホストフィックス-(バージョン) | オンライン バージョンの緊急修正ブランチは、開発とテストの両方で使用されるブランチと同じです。 | 開発開始からリリースまで | 開発会社 | 特定のニーズに合わせてカスタマイズされたバージョンの開発コードアクティビティ履歴を記録します。 | プロジェクトは存続期間中は存在し、廃止された後はアーカイブされます。 | テスト（会社） | 特定のニーズに合わせてカスタマイズされたバージョンのテスト コード アクティビティの履歴を記録します。 | dev-(会社)と同じ | 機能-(会社名)-v1.0.2-(名前) | これは、個々の開発者が作成したカスタムバージョンの開発活動履歴を指します。例えば、DavidがAlibabaの1.0.1のカスタムバージョンを開発している場合、ブランチ名はfeature-ali-v1.0.1-davidとなります。 | 開発開始からリリースまで、そしてリリースから完了まで。 | 開発版v1.0.2 | 複数のブランチにまたがって同時に開発を行う場合、特定のバージョンの開発コードアクティビティ履歴を記録します。 | 開発開始からリリースまで | テストv1.0.2 | 複数のブランチにまたがって同時に開発を行う場合、特定のバージョンのテストコードのアクティビティ履歴を記録します。 | 開発開始からリリースまで |
3. タグ タグの命名 | 説明する | ライフサイクル | タグ-v(ver) | タグ付けはリリースバージョンにのみ適用されます（例：tag-v1.0.0.1）。 | プロジェクトは存続期間中は存在し、廃止された後はアーカイブされます。 |
IV. Gitブランチガイドライン1. 分岐作業の基本原則マスター: システムバージョンのベンチマーク。バージョンがテストに合格し、リリースの準備が整った場合にのみ、マスターにマージされ、ビルド可能な状態になります。 dev*: 共同開発ブランチ。直接コミットすることはできず、他のブランチからマージすることしかできません。 test*: テスト ブランチ。直接コミットすることはできず、dev* ブランチからのマージによってのみ入力できます。 feature*: 個人開発ブランチ。個人開発が完了したら、devブランチにマージする前に、まずリモートのfeatureブランチにプッシュしてください。 2. 一般的なプロジェクト開発 ワークフローは上の図に示されています。 - プロジェクト マネージャーはマスター ベースラインからチェックアウトし、開発ブランチを初期化します。
- 開発者は dev ブランチをチェックアウトし、ローカルの個人開発ブランチ feature* を作成します。
- 機能開発が完了したら、開発者は個人の機能* ブランチをコミットし、それをリモートの個人の機能* ブランチにプッシュします。
- 開発者は GitLab の dev ブランチにコードを送信します。
- コード レビュー担当者は、コードをレビューし、適切なコードをマージする責任を負います。
- テスト用にコードを送信する場合、開発リーダーは dev ブランチから test ブランチにマージ リクエストを送信します。
- プロジェクト マネージャーは dev ブランチを test ブランチにマージしました。
- バージョン テストが完了したら、開発リーダーはテスト ブランチからマスター ブランチにマージ リクエストを送信します。
- プロジェクト マネージャーはコードをマスター ブランチにマージしました。
- プロジェクト リーダーは現在のコードをベースラインとして使用し、マスター ブランチに現在のバージョン番号をタグ付けします。
3. Hostfixのバージョン開発Hostfixは緊急対応バージョンであり、通常のバージョンとはワークフローが異なります。ワークフローは下図の通りです。 4. カスタマイズ版の開発特定のユーザーに特別な機能を提供する場合や、メインブランチとは異なるビジネスロジックがある場合に、カスタマイズバージョンが作成されます。ワークフローは以下の図に示されています。 5. 複数のバージョンを並行して実行するバージョンテスト中、開発チームはテスターからのバグ報告を心待ちにしているかもしれません。複数のバージョンを適切に連携させながら並行開発することで、時間を効率的に活用し、バージョン間のイテレーションを加速させることができます。ワークフローは下図に示されています。 | 