概要
組織で Git を導入する際に Git に対してむずかしそうというイメージを持たれることがよくあり、導入への障壁となることがある。その障壁を減らすために、Git を利用する上での最小限の知識の整理を行い、組織でとりあえず Git 利用の開始を実施したい方向けガイドとして本記事の投稿を行うこととした。
Git とは、ソースコードなどの変更履歴を記録・追跡するためのシステムである。Git に関する書籍や記事は多数あるが、ヌーラボ社の次の記事が参考となる。利用している Git プロバイダーが Backlog であるなどの注意点がある。
Git 入門
Git の利用を開始するために
Git の利用を開始するためには、次の項目の理解が必要である。
- Git の利用方法
- リポジトリーとブランチ
- リポジトリーの基本操作
- プルリクエスト（pull request、PR）
- コンフリクト（競合）
- Git フロー（git-flow）
- Git の応用機能
Git を用いた開発を行う際には、ヌーラボ社の記事に記載されている次のフローを実施する。
参照元：プルリクエストを使った開発プロセス｜サル先生のGit入門【プロジェクト管理ツールBacklog】
1. Git の利用方法
Git に関する書籍などでは CLI の利用方法が説明されていることがよくあるが、コマンドラインの利用に慣れていない場合には、GUI 操作により Git の利用を開始することがおすすめである。GUI 操作できるツールには、次のようなものがある。
- Visual Sutido Code
- GitHub Desktop
- Visual Studio Team Explorer
Git には多数のコマンドがあるが、Git の動作に慣れるまでは利用しない方がよい。操作を検索した情報に基づき実行した場合に、想定外の動作となり、いわゆる Git の迷子状況になってしまう場合がある。コミットやプルリクエストなどのリポジトリーへの反映処理を中心に利用を開始する。コンフリクトに対してファイルを別のディレクトリで退避させ新たなリポジトリーで対応を行うなど、組織への導入に対する精神的な利用障壁を下げる必要がある。
2. リポジトリーとブランチ
リポジトリーとは、ファイルやディレクトリなどの資材を保管する領域である。Git ではレポジトリーを複数のラインに同時に分割でき、その分割したものをブランチと呼ぶ。Git を利用する際には、複数のレポジトリーと複数のブランチを用いて開発を行う。ブランチなどのGit での管理方針は ブランチ戦略と呼ばれる。ブランチの概念を利用するには、ヌーラボ社の記事に記載されている図が参考となる。
参照元：ブランチとは｜サル先生のGit入門【プロジェクト管理ツールBacklog】
リポジトリーに対して作業を実施する際には、基本的には、特定のレポジトリーから作業用のリポジトリを複製（クローン）する。複製元をリモートレポジトリーと呼び、複製したものをローカルレポジトリーと呼ぶことがある。ローカルレポジトリーに対して資材の反映（コミット）して、リモートレポジトリーに反映（プッシュ）する。詳細については、次のリンクに記載されている。
複数人が資材の反映が実施されることで品質を担保できないため、リリース可能な状態を維持するためのブランチとして統合ブランチ（ main ブランチ）を定義する。統合ブランチに対しては、コミットの実施を制限し、承認を必要とする資材の反映（プルリクエスト）を行うことが一般的である。
Git による資材反映は、反映先とのコード差分から反映対象を判断するのではなく、内部で記録されている修正記録に基づき反映が実施される。詳細については、次のリンクに記載されている。
3. リポジトリーの基本操作
リポジトリーの基本的な操作には次のものがあり、自分の作業によりどのような処理が実施されるかを理解する必要がある。
- clone
- checkout
- pull
- fetch
- push
- merge
4. プルリクエスト（pull request）
プルリクエストを実施する際には、Git プロバイダー（Github、Azure Repos）にて実施します。プルリクエストに関する記事としては、次のものが参考になる。
- プルリクエストとは？｜サル先生のGit入門【プロジェクト管理ツールBacklog】
- プルリクエストのメリット｜サル先生のGit入門【プロジェクト管理ツールBacklog】
- プルリクエストを使った開発プロセス｜サル先生のGit入門【プロジェクト管理ツールBacklog】
6. コンフリクト（競合）
たとえば、Azure DevOps では次の拡張機能を用いることでコンフリクトを確認できるが、基本的にはどちらかの資材のみを残す対応は望ましくない
6. ブランチ戦略
次の２つのケースへの対応方針を検討する必要がある。
- コードの開発
- 環境へのデプロイ
有名なブランチ戦略には、次のものがあるが管理が煩雑が懸念があり、シンプルな管理にすることが望ましい。
- git flow
- github flow
7. Git の応用機能
Git には多くの機能があるが、次の応用機能の利用が必要となる場合がある。
- Git 上のファイル管理を行うファイル
Git 上のファイル管理を行う際に、利用されるファイルには次のものがある。
| # | ファイル名 | 概要 |
|---|---|---|
| 1 | .gitignore | Git 上で管理対象外とするファイルやディレクトリを指定する。ユーザーごとに自動で生成されるようなファイルを指定する。 |
| 2 | .gitkeep | ファイルが存在しないディレクトリを Git 管理対象とする場合にディレクトリ上に作成するファイル。 |
.gitignoreのテンプレートが次のレポジトリーにて公開されている。
Git 利用指針
プロジェクトで利用するリポジトリー数
次のような方針を検討する。
- サービスごとリポジトリーを作成
- 複数のサービスのグループごとにリポジトリーを作成
- 単一のレポートを作成
Git フロー
1. コードの開発への対応方法としては、次のような方法を検討する。
- 通常の開発
- main ブランチから開発ブランチを作成
- 開発ブランチからタスクに応じて作業ブランチを作成
- 作業ブランチに、作業を実施後、資材をコミット
- 作業ブランチから、開発ブランチにプルリクエストにより反映
- 開発ブランチを main ブランチにプルリクエストにより反映
- バグ対応（Hotfix 対応）
- main ブランチから Hotfilx 対応ブランチを作成
- Hotfilx 対応ブランからタスクに応じて作業ブランチを作成
- 作業ブランチに、作業を実施後、資材をコミット
- 作業ブランチから、 Hotfix 対応ブランチにプルリクエストにより反映
- Hotfix 対応を main ブランチにプルリクエストにより反映
- Hotfix 対応を開発ブランチにプルリクエストにより反映
2. 環境へのデプロイへの対応方法としては、次のような方法を検討する。
- 環境ブランチによりデプロイする方法
- 環境タグによりデプロイする方法
ブランチ名
次のケースにおけるブランチ名を検討する。
- 開発ブランチ
- リリース時期（例：
develop_202312）
- リリース時期（例：
- 作業ブランチ
- アサインされているタスク（例：
requirement/8660）
- アサインされているタスク（例：
- 開発環境へのリリースブランチ
- dev
- 検証環境へのリリースブランチ
- stg
- 本場環境へのリリースブランチ
- prd