最近の構成管理はGitが主流となってきています。
構造、機能、リポジトリパターンなど、いろいろと難しいところがありますので、まとめて説明していきます。
Gitはブランチ単位にファイルをファイルと更新履歴を管理しています
リポジトリ作成時にデフォルトで”master”ブランチが作成されます。
ユーザはクライアントPCにブランチをクローン（”Clone”、コピーと同義）し、クライアント側のファイルを編集します。
サーバー側、クライアント側のファイルが更新された場合は同期することで最新化を行います。
サーバーからクライアントへの同期をプル（”Pull”）、クライアントからサーバーへの同期をプッシュ（”Push”）と言います。
同期は基本的にブランチ単位で実施します。
クライアントにクローンを実行すると、リポジトリと同じディレクトリ構成が作成されますが、
“.git”ディレクトリも作成されます。
“.git”ディレクトリはリポジトリと同じように、ブランチや更新履歴が保存されていますが、
このフォルダ内部を直接変更することはありません。
このフォルダをローカルリポジトリと言い、サーバーのリポジトリをリモートリポジトリと言います。
ユーザは自分が指定したフォルダにできたファイルを修正し、コミットすることで、
ローカルリポジトリに更新履歴として保存されます。
さらにプッシュすることで、リモートリポジトリにも同期されます。
2人以上で作業する場合、同じファイルを修正する可能性があります。
同じファイルを別々にプッシュした場合、あとからプッシュしたユーザがエラーとなります。
そのため、ファイルを変更する前にリモートブランチの最新の状態をプルし、
そのうえで修正、コミット、プッシュする必要があります。
しかし、これでは作業が滞ってしまうので、複数人で同じリポジトリを使用する場合は、
ユーザ単位や作業単位でブランチを分けて管理します。
開発中の状態などは自分のブランチのみを使用します。
他のユーザへの展開を行いたい場合はマスターブランチなどの上位のブランチにプッシュする必要がありますが、
この時は、いったん自身のローカルリポジトリにマスターブランチをプルし、ローカルリポジトリ内でマージします。
その後、マスターブランチにプッシュすることで、他のユーザへの展開を行います。
この時、プルリクエストを実施すると他のユーザにメールでプルしてくださいという内容のメールが飛びます。
もし、マージのタイミングで競合が発生した場合は、リモートとローカルの比較画面を利用して
正しい状態のファイルを作成し、マージ済みとして登録します。
マージしたファイルをローカルリポジトリのマスターブランチにマージし、プッシュします。
自身のリポジトリにもプッシュして最新化しておいた方がいいでしょう。
こうすることで、他者の更新と自身の更新の両方を反映した最新の状態をマスターブランチに作成することができます。
このタイミングでプルリクエストを送り他のユーザもマージすることで、すべてのユーザが常に最新の状態で作業することができます。
作業の流れをまとめると以下のようになります。
ブランチモデル
ブランチモデルとはどのブランチをどのように使うかをパターン化したものです。
マスターオンリー
もっとも単純なモデルです。
一人で開発する場合など、競合が発生しない場合はこのモデルで開発することでプッシュなどの手間を省くことができます。
GitFlowモデル
もっとも一般的なモデルです。
masterブランチからdevelop（開発）ブランチを作成し、さらにfeature（機能）ブランチを作成し、featureブランチで開発を行います。
全ての機能の開発完了後、developブランチにマージし、masterに反映します。
リリース作業を行う場合はreleaseブランチを作成し、リリース作業完了後に削除します。
（masterブランチでリリース作業を行う場合は不要）
リリース後に次のバージョンの開発を行う場合など、現行バージョンの維持と開発が並行で行われているときにバグフィックスが必要な場合は、
hotfixブランチを作成してバグフィックスを行います。
バグフィックスが完了したらmasterブランチにマージしてリリース作業を行います。
この時、developブランチにもマージすることでバグフィックスの内容を開発環境にも反映させることができます。
GitHub Flowモデル
masterブランチを用いて複数人で開発することができるシンプルなモデルです。
masterブランチをメインとしてfeatureブランチを作成し、開発を行います。
各featureの開発が完了したらmasterブランチにマージし、リリースを行います。
masterブランチはリリース可能なブランチという位置づけのため、
マージ前のfeatureブランチでテストとレビューが完了している必要があります。
GitLab Flowモデル
GitLab Flowは、GitHab Flowモデルをベースとして、自動デプロイやマージからデプロイまでに検証や認証が必要な場合、複数のバージョンが並行稼働する場合などを考慮したブランチモデルです。
用途に応じて必要なブランチを追加して運用します。
productionブランチ
リリース管理が必要な場合にproductionブランチを利用します。
特定のブランチへのマージにより自動的にデプロイしたい場合や、masterブランチがデプロイされているソースと乖離が発生する場合などは、productionブランチを作成し、productionブランチのソースがデプロイ中のソースとして管理します。
環境ブランチ
リリース前に検証環境での確認が必要な場合はpre-productionブランチを利用します。
検証環境テストバージョンをpre-productionブランチで管理し、検証が完了したらproductionブランチにマージし、リリースします。
releaseブランチ
複数のバージョンが並行稼働する場合はreleaseブランチを利用します。
下記の例ではreleaseブランチとしてstable1,stable2というブランチを作成し、それぞれバージョン1系、バージョン2系をデプロイしています。
バグフィックスが発生した場合、各releaseブランチにマージしリリースする必要がありますが、stable1にマージしてしまうとバージョン2系がすべてマージされてしまいます。
そこで、今回のバグフィックスのみマージするcherry-pick機能を利用することで、パージョン1系のバグフィックスを行うことができます。
