いまさら聞けないGitHub再入門

はじめに

Git管理を周りに任せきりではなく、自分自身も全体の仕組みをしっかり理解したい、という私を含めた管理層に向けた内容です。
Gitは一見難しく感じるかもしれませんが、基本的な概念と作業の流れをつかんでしまえば、チーム開発を円滑に進める強い味方になり、この理解を深めることが開発管理の助けになると考えています。

基本概念

まずはGitやGitHubを使ううえで重要となる用語です。なるべくわかりやすい補足を入れています。

• リポジトリ (Repository)
  コードやその変更履歴を保存する「入れ物」です。
  例えるなら「作品集をしまっておくフォルダ」と考えてください。
• クローン (Clone)
  リモートリポジトリ（GitHubなどクラウド上に置いているもの）のコピーを、自分のパソコン（ローカル）に作ることです。
  インターネット上の「作品集」を自分のパソコンにも同じものをまるごとコピーしてくるイメージです。
• ブランチ (Branch)
  メインとなるコードベース（大元の絵）から分岐して作業を進めるための独立した作業スペースです。
  大きな川（メインコード）から支流（ブランチ）が分かれるイメージです。
• コミット (Commit)
  変更を記録するスナップショットのことです。
  「宿題の進捗を先生に提出する」ようなイメージで、作業の区切りを確定させます。
• ステージング (Staging)
  コミット前に変更を準備する場所のことです。
  「提出予定の宿題をまとめて一旦カバンに入れる」ような感覚です。
• プッシュ (Push)
  ローカル（自分のパソコン）の変更をリモートリポジトリに送信する操作です。
  「手元で作った作品をクラウド上の共有フォルダにアップロードする」イメージです。
• プル (Pull)
  リモートリポジトリ上の変更を自分のパソコンに取り込む操作です。
  「クラウドにある最新の作品を自分のパソコンにダウンロードしてくる」イメージです。
• プルリクエスト (Pull Request)
  変更をメインブランチなどにマージしてほしいと提案する仕組みです。
  チームメンバーに「作った作品を合流していいか見てほしい」とお願いする感じです。
• マージ (Merge)
  あるブランチの変更を別のブランチに取り込む（統合する）操作です。
  「みんなの作った作品を一つの作品集にまとめる」ようなイメージです。

ペルソナ別コマンドと作業フロー

ここでは、Gitを扱う役割（ペルソナ）ごとに、よく使うコマンドと作業の流れをまとめます。
大事なコマンドは専門用語のまま記載しますが、同時にやっていることを簡単に補足していきます。
全体的なフローは下記となります。

GitHub開発ワークフロー：ペルソナ別図解

1. 開発者

役割: 日常的にコードを書き、変更を管理する人。
目的: 新機能の開発や既存機能の改善、バグ修正など。

主要コマンド

# リポジトリを初めて取得（クローン）
git clone https://github.com/organization/repository.git

# 最新の変更を取得（プル）
git pull origin main

# 新しいブランチを作成して切り替え
git checkout -b feature/new-feature

# 変更をステージングに追加
git add file.txt       # 特定ファイルのみ
git add .              # 全ての変更

# 変更をコミット
git commit -m "機能Aを実装"

# リモートリポジトリにプッシュ
git push origin feature/new-feature

# 作業中のブランチの状態確認
git status

# 変更差分の確認
git diff

一般的なワークフロー

1. 最新のmainブランチを取得: git pull origin main
   • みんなの最新作業内容を自分の環境に取り込みます。
2. 新しい機能ブランチを作成: git checkout -b feature/xyz
   • メインのコードから作業用の枝を作ります。
3. コード変更を実施
   • ここで実際にファイル編集を行います。
4. 変更をステージング・コミット: git add → git commit
   • 変更を記録（スナップショット）に残し、履歴をしっかり残します。
5. リモートリポジトリにプッシュ: git push
   • 作業内容をみんながアクセスできるクラウドにアップします。
6. プルリクエストを作成（GitHubのUIなどで）
   • チームに「合流していいかレビューしてほしい」と提案します。
7. レビューのフィードバックに対応
   • 指摘があれば修正して、再コミット・再プッシュします。
8. 承認後、マージ
   • みんなの作業ブランチに統合します。

2. レビュアー / 承認者

役割: コードの品質と一貫性をチェックする人。
目的: チーム全体の品質維持やバグの早期発見。

主要コマンド

# レビュー対象のブランチをローカルに取得
git fetch origin pull/123/head:review-branch-123
git checkout review-branch-123

# 変更履歴を確認
git log

# 特定コミットの詳細確認
git show <commit_hash>

# 特定ファイルの変更履歴確認
git blame file.txt

一般的な作業

1. GitHubのプルリクエスト画面でプルリクエストを確認
2. コードレビューコメントを追加
3. 必要に応じてローカルでコードをテスト
4. 修正要求または承認

3. プロジェクトマネージャー / チームリード

役割: プロジェクト全体の進行や品質を管理する人。
目的: スケジュール管理や大きな方針を決めながら、チームがスムーズに開発できるよう整える。

主要コマンド

# リリースタグの作成
git tag -a v1.0.0 -m "バージョン1.0.0リリース"
git push origin v1.0.0

# プロジェクト状況の可視化
git log --graph --oneline --all

# ブランチの管理
git branch -a                  # 全ブランチ表示
git branch -d feature/done     # 完了ブランチの削除

一般的な作業

1. リリース計画の管理
2. ブランチ戦略の決定と監督
3. マージ競合の解決支援
4. リリースタグの管理

4. DevOps / CI/CD担当者

役割: 自動化とデプロイメントパイプラインを管理する人。
目的: テストやデプロイのフローを自動化して、品質を保ちながら素早くリリースできるようにする。

主要コマンド

# CI/CDのための特定コミットのチェックアウト
git checkout <COMMIT_HASH>

# デプロイ用タグの確認
git describe --tags

# サブモジュールの更新
git submodule update --init --recursive

一般的な作業

1. GitHub Actionsなどのワークフロー設定
2. デプロイメントスクリプト管理
3. ビルド・テスト環境の整備

5. リポジトリ管理者

役割: リポジトリの設定やアクセス権などを管理する人。
目的: セキュリティや運用体制を整備し、チームが開発しやすい環境を用意する。

主要コマンド

# リモートリポジトリ設定の確認
git remote -v

# リポジトリ設定の変更（例：ユーザー名）
git config --local user.name "チーム名"

# GitHubのテンプレート設定
# (主にGitHub UI経由で設定することが多い)

一般的な作業

1. ブランチ保護ルールの設定
2. アクセス権限の管理
3. Webhookやインテグレーションの設定
4. Issue・プルリクエストテンプレートの管理

一般的な開発フロー例（Gitflow）

代表的な開発フローとして、Gitflowという手法があります。
ざっくりとした流れは以下のようになります。

1. 開発者がdevelopブランチからfeature/xyzブランチを作成
2. 開発完了後、developへのプルリクエスト作成
3. レビュアーが確認し、承認
4. developへのマージ
5. リリース時、release/v1.xブランチを作成
6. テスト完了後、mainとdevelopの両方にマージ
7. mainにタグ付け (v1.x.x)

一般的なコマンド対応表

操作	コマンド	主に使用するペルソナ
リポジトリ複製	git clone	開発者、レビュアー
変更取得	git pull	全員
変更送信	git push	開発者、管理者
ブランチ作成	git checkout -b	開発者
変更準備（ステージ）	git add	開発者
変更記録（コミット）	git commit	開発者
プルリクエスト作成	GitHub UI	開発者
プルリクエストレビュー	GitHub UI	レビュアー、チームリード
マージ	git merge / GitHub UI	レビュアー、チームリード
リリース	git tag	チームリード、DevOps

まとめ

Gitの仕組みを理解すると、チーム開発で「誰が何をいつ変えたのか」をしっかり追跡できるようになります。ぜひ、この記事をご参考にして頂けると幸いです！