June's Blog

紹介: チームの Git ブランチ管理の規範を統一するために、最初は自分で書く準備をしていましたが、インターネットで検索してみると、いくつかの良い Git ブランチ管理の実践が見つかりました。

現在のチームの使用方法を参考にして、より Git フローに近づけるために、現在欠けているのはリリースブランチです。

最終的に、チームのためにこの Git ブランチ管理の実践を選びました A successful Git branching model)。この記事を参考にした中国語版の Git フロー実践がインターネット上に多くあります。中国語版の Git のベストプラクティスをおすすめします：有効な Git ブランチモデル)

よく使われる Git フローには、git-flow、github-flow、gitlab-flow があります。

記事を転載します：Gitflow、Github flow、Gitlab flow のワークフローを理解するための記事

さらに、ツールgitflowを使用して、git-flow ブランチ管理モデルを簡単に使うことができます。

GitHub Flow#

特徴：#

デプロイを中心とした開発モデルで、シンプルな機能とルールにより、継続的かつ高速に安全にデプロイを行います。

• master ブランチは常にデプロイ可能な状態を保ちます
• 新しい作業を開始する場合は、master ブランチから新しいブランチを作成し、新しいブランチの名前には説明的な名前を付けます
• master ブランチとマージした後、すぐにデプロイします

前提条件#

• デプロイ作業は完全に自動化されています。自動化されていなければならず、1 日に複数回のデプロイが必要です
• テストに重点を置く
  • テストを自動化する
  • テストコードを書き、すべてのテストに合格する
  • テストコードを維持する

Git Flow#

オランダのプログラマー、Vincent Driessen は、ブログで広く知られるブランチ戦略を紹介しました。具体的な手順は以下の図を参照してください（このブログの画像を引用）

高品質の PDF： https://nvie.com/files/Git-branching-model.pdf

Git Flow では、master ブランチと develop ブランチが非常に重要であり、プロセス全体を通じて維持され、開発者が直接変更やコミットを行うことは絶対に許されません。

develop ブランチを起点に feature ブランチを作成し、feature ブランチで新しい機能の開発やコード修正を行います。つまり、develop ブランチは開発プロセス中の最新のコードを維持し、開発者が自分の作業を行うための feature ブランチを作成するためです。

規範#

メインブランチ master#

まず、コードリポジトリには 1 つのメインブランチが必要です。すべてのユーザーに提供される公式バージョンは、このメインブランチでリリースされます。

開発ブランチ develop#

メインブランチは重要なバージョンのリリースにのみ使用され、日常の開発は別のブランチで行うべきです。開発用のブランチは Develop と呼ばれます。

一時的なブランチ#

使用後は削除する必要があり、コードリポジトリには常に Master と Develop の 2 つのブランチしかありません。

• 機能（feature）ブランチ

• 特定の機能から Develop ブランチを分岐させます。開発が完了したら、Develop にマージします。

• リリース（release）ブランチ

• 公式バージョンをリリースする前（つまり、Master ブランチにマージする前）に、テスト用のリリースバージョンが必要な場合があります。

  リリースブランチは Develop ブランチから分岐し、リリースが終了したら、Develop と Master ブランチにマージする必要があります。リリース名は、release-* の形式で命名することができます。

• バグ修正（fixbug）ブランチ

• Master ブランチから分岐します。修正が完了したら、Master と Develop ブランチにマージします。修正の名前は、fixbug-* の形式で命名することができます。

Git-flow の簡単な例#

詳しい使用方法はこちらを参照してください： https://jeffkreeftmeijer.com/git-flow/

mac では、homebrew を使用して git-flow をインストールします：

brew install git-flow

プロジェクトの初期化：git flow init#

feature ブランチでの作業フロー：git flow feature start xxxx#

• develop ブランチから feature ブランチを作成します
• feature ブランチで目標の機能を実装します
• Github を介して develop にプルリクエストを送信します
• 他の開発者による承認後、Pull Request をdevelop ブランチにマージします

feature 機能の開発が完了したら：git flow feature finish xxxx

Develop ブランチは保護されているため、まず feature ブランチをリモートにプッシュしてから、pr を dev ブランチにマージすることをお勧めします

元のブランチを保持するコマンド： git flow feature finish -k my-feature

参考： https://github.com/nvie/gitflow/wiki/Command-Line-Arguments

gitlab または paas で pr を提出する

!!!! インポート：develop ブランチを更新する

私たちが送信した pull request は、github で develop ブランチとマージされた後、それがローカルの develop ブランチに反映されるようにするために、以下の手順を実行する必要があります：

• develop ブランチに切り替える
• git pull（fetch & merge）を実行する

develop ブランチから feature などのブランチを作成する必要がある場合は、必ず上記の手順を実行して、develop ブランチが最新の状態にあることを確認してください

リリースの準備#

リリースブランチを作成し、このブランチではリリースの準備に関連するコミットのみを処理します。ソフトウェアがテスト環境にデプロイされ、バグが見つかった場合、関連する修正もこのブランチにコミットする必要があります。

注意：このブランチには要件の変更や機能の変更などの重大な修正を含めるべきではありません。この段階のコミット数は最小限に抑えるべきです

すべての修正が完了したら、このブランチを終了します

よくある問題と解決策#

特性ブランチのマージコンフリクト#

問題：特性ブランチを完成させ、develop ブランチにマージしようとすると、マージコンフリクトが発生することがあります。

解決策：

• マージする前に、develop ブランチの最新の変更がローカルに取り込まれていることを確認します。
• マージを実行するために git merge --no-ff <feature-branch> を使用し、マージ操作を履歴に残すようにします。
• コンフリクトの解決には手動で行い、git add <conflicted-file> を使用して解決したファイルを追加し、git commit でマージをコミットします。

特性ブランチが多すぎて管理が難しい#

問題：時間の経過とともに、プロジェクトには多くの特性ブランチが蓄積される可能性があります。

解決策：

• 定期的に不要な特性ブランチをクリーンアップします。
• git branch -d <feature-branch> を使用してローカルブランチを削除し、git push --delete origin <feature-branch> を使用してリモートブランチを削除します。
• チームメンバーに対して、特性ブランチの完了または廃止の重要性を強調するトレーニングを行います。

リリースブランチのマージ問題#

問題：リリースの準備をするために develop ブランチから作成された release ブランチが、master と develop にマージする際に問題が発生することがあります。

解決策：

• リリースブランチを作成する前に、develop ブランチが安定していることを確認します。
• master にマージする前に、すべてのテストがパスすることを確認します。
• git flow release finish コマンドを使用する際に、自動生成されたマージリクエストを注意深く確認します。

緊急修正ブランチの管理#

問題：緊急の修正は master と develop ブランチに迅速にマージする必要があります。

解決策：

• git flow hotfix start <hotfix> を使用して、緊急修正ブランチを迅速に作成します。
• 修正が完了したら、git flow hotfix finish <hotfix> コマンドを使用し、master と develop にマージされることを確認します。
• マージ後にバージョン番号と関連するドキュメントを更新することを確認します。

複数のチームの協力の衝突#

問題：大規模なプロジェクトでは、複数のチームが同時に異なる特性ブランチで作業することがあります。

解決策：

• コードレビューとマージにはプルリクエストを使用します。
• 定期的にチームミーティングを開催し、進捗と潜在的なマージの衝突について話し合います。
• タグとマイルストーンを使用して、各チームの作業の進捗を追跡します。