はじめに

Gitは現在のソフトウェア開発では標準的なツールですが、久しぶりに触るとコマンドや運用フローを忘れてしまうことがあります。また、チームへ展開しようとすると、どこまで整理して説明すればよいか悩みがちです。

組込み開発の現場では、ZIP管理や共有フォルダ運用が残っているケースもあり、

誰がいつ何を変更したかわからない
リリースしたソースを後から特定できない
車体評価で使ったバイナリとソースが一致するかわからない

といった問題に遭遇することがあります。

Gitは、こうした課題を構造的に解決するためのツールです。

この記事では、自分自身の整理も兼ねて、Gitの基本操作からブランチ・Pull Request・タグ運用まで、チーム開発を意識した基本的な流れをまとめます。

GitHubを前提に説明しますが、GitLab利用時の読み替えポイントも随所に補足します。

1. Gitの基本概念を理解する

操作を覚える前に、Gitがどういう仕組みで動いているかをざっくり掴んでおきます。ここを理解しておくと、コマンドが「何をしているのか」わかるようになり、迷いにくくなります。

1.1 バージョン管理とは何か

バージョン管理とは、ファイルの変更履歴を記録・管理する仕組みです。

ZIPで管理する場合、「いつの状態か」はファイル名やフォルダ名に埋め込むしかありません。Gitでは、変更のたびにコミットという単位で履歴を記録します。コミットには日時・作者・変更内容・コメント（コミットメッセージ）が含まれるため、後からいつでも任意の時点の状態に戻せます。

1.2 3層モデル（ワーキングツリー・ステージング・リポジトリ）

Gitでは、ファイルが以下の3つの領域を経由して記録されます。

[ワーキングツリー] → git add → [ステージングエリア] → git commit → [ローカルリポジトリ] → git push → [リモートリポジトリ]

領域	説明
ワーキングツリー	実際にファイルを編集する場所。普段作業しているフォルダそのもの
ステージングエリア	コミットする変更を「選んで準備する」場所。`git add` で追加する
ローカルリポジトリ	自分のPCの中にある履歴データベース。`git commit` で記録される
リモートリポジトリ	GitHubやGitLab上にある共有用のリポジトリ。`git push` で同期する

「なぜaddとcommitが分かれているのか」と思うかもしれません。これは「複数ファイルを変更したが、今回のコミットには関係するファイルだけを含めたい」という場面で役立ちます。コミット単位を意味のある粒度にできるのがGitの強みの一つです。

1.3 ブランチとは何か

ブランチとは、開発の流れを枝分かれさせる仕組みです。

たとえば、メインのコードに手を加えずに新機能の開発を試したいとき、ブランチを作ることで安全に作業できます。作業が完了したらメインのブランチに統合（マージ）します。

main    ----o----o-----------o----
                  \         /
feature            o----o--o

main（またはmaster）：安定したコードが置かれるデフォルトブランチ
feature/xxx：新機能や修正作業用に切るブランチ

mainに直接コミットし続けると、誰かの変更が別の人の作業を壊す事故が起きます。ブランチを使うことでこれを防げます。

ブランチの運用ルールはブランチ戦略と呼び、チームの規模や運用方針によっていくつかの流派があります。

ブランチ戦略について
本記事ではブランチの基本的な使い方に絞っています。Git FlowやGitHub Flowなどの戦略については以下が参考になります。
https://qiita.com/trsn_si/items/cfecbf7dff20c64628ea

1.4 GitHubとGitの関係

Git：バージョン管理を行うツール本体。コマンドラインで操作する
GitHub：Gitのリモートリポジトリをホスティングするサービス。Pull RequestやIssueなどのチーム開発機能も提供する

GitはGitHubがなくてもローカルで使えます。ただしチームで共有するにはリモートリポジトリが必要なので、実務ではGitHubやGitLabと組み合わせて使います。

2. 基本操作を身につける

2.1 リポジトリの作成（init / clone）

リポジトリの作成には2つのケースがあります。新しく始める場合は init、既存のリポジトリから始める場合は clone を使います。どちらか該当する方を参照してください。

新しくリポジトリを作る場合（init）

ローカルに新しいリポジトリを作成します。

mkdir my-project
cd my-project
git init
# Initialized empty Git repository in .../my-project/.git/

GitHubにリモートリポジトリを作成し（GitHub上で New repository）、紐付けます。

git remote add origin git@github.com:username/my-project.git

既存リポジトリをコピーして始める場合（clone）

git clone git@github.com:username/my-project.git
cd my-project

cloneすると、リモートリポジトリの内容がローカルにコピーされ、リモートとの紐付けも自動で設定されます。

2.2 変更を記録する（add / commit）

ファイルを編集したら、以下の手順で記録します。

# 変更状態を確認（まずこれを打つ習慣を）
git status

# 変更ファイルをステージングに追加
git add ファイル名
# または全変更を一括追加
git add .

# コミット（変更の記録）
git commit -m "変更内容を説明するメッセージ"

良いコミットメッセージのポイント

何をしたかではなく、なぜしたかを書く
例：fix: センサ値の単位変換ミスを修正 / feat: 車速リミット機能を追加

2.3 リモートに反映する（push / pull）

# ローカルの変更をリモートに送る
git push origin main

# リモートの変更をローカルに取り込む
git pull origin main

チームで作業していると、自分がpushする前に他の人がpushしていることがあります。その場合は先にpullしてからpushします。

2.4 状態確認の習慣（status / log）

操作に迷ったらまずこの2つを打ちます。

# 現在の状態を確認（どのブランチにいるか、何が変更されているか）
git status

# コミット履歴をグラフ表示
git log --oneline --graph --all

git log --oneline --graph --all は、ブランチの分岐・合流が視覚的に確認できるので特に有用です。「今自分がどこにいるのか」を把握するのに使ってください。

3. チームでの運用フロー

3.1 ブランチを切って作業する

新しい作業を始めるときは必ずブランチを作ります。

# ブランチを作成して切り替え
git switch -c feature/add-speed-limit
# （旧コマンド: git checkout -b feature/add-speed-limit）

# 現在のブランチを確認
git branch

作業が完了したらコミットし、リモートにpushします。

git add .
git commit -m "feat: 車速リミット機能を追加"
git push origin feature/add-speed-limit

3.2 Pull Requestを作成してレビューを受ける

GitHubにpushすると、画面上に「Compare & pull request」ボタンが表示されます。

PRを作成するときに記載する内容：

タイトル：変更内容を一言で
説明：何を・なぜ変えたか、レビュアーに確認してほしいポイント
レビュアー：確認してほしい人を指定

レビューのやりとりはPRのコメント欄で行います。指摘を受けたら修正してコミット・pushすれば、自動的にPRに反映されます。

3.3 mainにマージする

レビューが承認されたらmainにマージします。GitHubのUI上で「Merge pull request」ボタンを押すだけです。

マージ後はfeatureブランチを削除してよいです（GitHub上で削除ボタンが表示されます）。ローカルの後始末：

git switch main
git pull origin main
git branch -d feature/add-speed-limit

3.4 リリースバージョンを明示する（tag）

リリース時にはタグを打つことで、そのコミットが「どのバージョンのリリースか」を明示できます。

# タグを作成
git tag -a v1.0.0 -m "初回リリース"

# リモートにタグをpush
git push origin v1.0.0

タグを使うことで、開発中・リリース済み・車体検証で使ったソースが一致しているかを後から確実に確認できます。git checkout v1.0.0 でその時点のソースに戻ることも可能です。

📝 GitLab読み替えコラム

GitHub	GitLab
Pull Request (PR)	Merge Request (MR)
`Compare & pull request` ボタン	`Create merge request` ボタン
マージ後のブランチ削除オプション	同様にUI上で可能

タグの操作はコマンドレベルでは同一です。

4. 困ったときの対処法

4.1 今の状態を把握する

まず落ち着いて現状を確認します。

git status        # 変更ファイルの状態
git branch        # 現在のブランチ
git log --oneline --graph --all  # 履歴とブランチの全体像

この3つで「今どこにいるか」はほぼ把握できます。

4.2 変更を一時退避する（stash）

作業途中で別のブランチに切り替えなければならないとき、コミットするほどではない変更を一時的に退避できます。

# 変更を退避
git stash

# ブランチを切り替えて作業...

# 退避した変更を戻す
git stash pop

4.3 コンフリクトを解消する

複数人が同じ箇所を変更してマージしようとするとコンフリクト（競合）が起きます。

git pull origin main
# CONFLICT (content): Merge conflict in src/main.c

コンフリクトが起きたファイルを開くと以下のようなマーカーが挿入されています。

<<<<<<< HEAD
自分の変更
=======
相手の変更
>>>>>>> origin/main

マーカーを含めて不要な部分を削除し、正しい内容に編集します。編集後：

git add src/main.c
git commit -m "merge: コンフリクト解消"

4.4 コミット前の変更を取り消す（restore）

まだコミットしていない段階であれば、以下で安全に取り消せます。

# ファイルの編集を取り消す
git restore ファイル名

# ステージングを取り消す（addを取り消す）
git restore --staged ファイル名

4.5 コミット履歴を修正・整理する（amend / rebase）

直前のコミットをやり直す（amend）

直前のコミット（HEAD）のみが対象です。メッセージの修正や、コミットし忘れたファイルの追加に使います。

git commit --amend -m "修正したメッセージ"

複数のコミットをまとめる・修正する（rebase -i）

--amend でカバーできない範囲の履歴整理はこちらを使います。PRを出す前に細かすぎるコミットをまとめたいときなどに有用です。

# 直近3件のコミットを対話的に編集
git rebase -i HEAD~3

エディタが開き、各コミットに対して pick（そのまま）/ squash（直前にまとめる）/ reword（メッセージ修正）などを指定できます。

ブランチの起点を付け替える（rebase）

featureブランチを切った後にmainが進んでいた場合、rebase でfeatureの起点をmainの最新に移せます。merge と似た目的ですが、履歴が直線になるのが違いです。

git switch feature/your-work
git rebase main

注意：rebase はすでにリモートにpushしたコミットには使わないでください。チームの履歴を壊す原因になります。push前のローカルでの整理に限定して使うのが安全です。

4.6 コミットを安全に取り消す（revert / reset）

履歴を残しながら取り消す（revert）

チームで作業中に誤ったコミットを取り消すときはこちらを使います。取り消しの記録自体が新しいコミットとして残るので履歴が壊れません。

git revert HEAD

コミットをなかったことにする（reset）

ローカルでのみ作業していてコミット自体を消したいときに使います。

# 直前のコミットを取り消す（変更内容はワーキングツリーに残る）
git reset HEAD~1

注意：reset はリモートにpushしたコミットには使わないでください。チームの履歴との整合が取れなくなります。

4.7 どうにもならないときの再clone

ローカルリポジトリの状態が完全にわからなくなったときは、再cloneが最もシンプルな解決策です。リモートリポジトリにpushした内容は失われません。

cd ..
rm -rf my-project
git clone git@github.com:username/my-project.git

5. ケース別クイックリファレンス

ケース1：初めてリポジトリを作って作業を始めるとき

# リポジトリ作成
mkdir my-project && cd my-project
git init

# GitHubでリポジトリ作成後、リモートを紐付け
git remote add origin git@github.com:username/my-project.git

# 最初のコミット
git add .
git commit -m "initial commit"
git push -u origin main

ケース2：既存リポジトリをクローンして作業を始めるとき

git clone git@github.com:username/my-project.git
cd my-project

# 作業用ブランチを作成
git switch -c feature/your-work

ケース3：コードを修正してコミット・プッシュするとき

# 状態確認
git status

# ステージング
git add 変更したファイル

# コミット
git commit -m "fix: 修正内容を説明するメッセージ"

# プッシュ
git push origin ブランチ名

ケース4：新機能をブランチで開発してPRを出すとき

# 最新のmainから作業開始
git switch main
git pull origin main
git switch -c feature/new-function

# 開発・コミットを繰り返す
git add .
git commit -m "feat: 新機能の説明"

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

# GitHub上でPull Requestを作成

ケース5：リリース版にタグを打つとき

# mainブランチで実施
git switch main
git pull origin main

# タグ作成
git tag -a v1.2.0 -m "v1.2.0リリース"

# リモートにプッシュ
git push origin v1.2.0

ケース6：コンフリクトが起きたとき

# まず状態確認
git status

# コンフリクトファイルをエディタで開いて編集（<<<, ===, >>> のマーカーを解消）

# 解消したファイルをステージング
git add 解消したファイル

# コミット
git commit -m "merge: コンフリクト解消"

ケース7：操作を誤って戻したいとき

# 編集を取り消す（コミット前）
git restore ファイル名

# addを取り消す
git restore --staged ファイル名

# 直前のコミットを取り消す（変更内容はワーキングツリーに残る）
git reset HEAD~1

# どうにもならないとき → 再clone
git clone git@github.com:username/my-project.git

ケース8：push前にコミット履歴を整理したいとき

# 直前のコミットメッセージを修正する
git commit --amend -m "修正したメッセージ"

# 直近3件のコミットをまとめる・修正する
git rebase -i HEAD~3
# エディタで squash / reword などを指定

ケース9：featureブランチの起点をmainの最新に付け替えたいとき

# mainを最新にする
git switch main
git pull origin main

# featureブランチの起点を付け替える
git switch feature/your-work
git rebase main

おわりに

自分の整理も兼ねて、基本操作からチーム運用フローまでをまとめました。

日常的に使うのは status add commit push pull の5つが中心で、ブランチやPRの操作も慣れれば流れで覚えられます。詰まったときはケース別リファレンスを起点に、4章の該当箇所を参照してみてください。

本記事はGitHub環境を前提に記述しています。GitLabをお使いの場合は各所の📝コラムを参照してください。

本記事と合わせて、C言語プロジェクトへのGitHub Actions CI構築についても別シリーズで解説する予定です。

付録：環境構築とセットアップ

はじめてGitを使い始めるときのみ必要な手順です。セットアップ済みの方はスキップしてください。

A.1 Gitのインストールと初期設定

インストール

Windows：https://git-scm.com/ からインストーラをダウンロードして実行
Mac：Xcodeコマンドラインツールに同梱。ターミナルで git --version を実行すると自動的にインストールを促される
Linux（Ubuntu/Debian）：sudo apt install git

インストール後、バージョンを確認します。

git --version
# git version 2.x.x

初期設定

コミットに記録される名前とメールアドレスを設定します。これは全リポジトリに適用されるグローバル設定です。

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

設定確認：

git config --list

A.2 GitHubアカウントの作成とSSH接続設定

GitHubアカウント作成

https://github.com/ でアカウントを作成します。

SSH鍵の生成

パスワード入力なしにGitHubと通信するためにSSH鍵を設定します。

# SSH鍵を生成（メールアドレスは自分のものに変更）
ssh-keygen -t ed25519 -C "your@email.com"
# 保存先・パスフレーズはそのままEnterでも可

公開鍵をGitHubに登録

# 公開鍵の内容を表示
cat ~/.ssh/id_ed25519.pub

表示された内容をコピーし、GitHubの Settings > SSH and GPG keys > New SSH key に貼り付けます。

接続確認

ssh -T git@github.com
# Hi username! You've successfully authenticated...

📝 GitLab読み替えコラム

GitLabの場合も手順はほぼ同じです。

アカウント作成：社内GitLabのURLにアクセス（管理者からURLを確認してください）
SSH鍵の登録先：Settings > SSH Keys
接続確認：ssh -T git@your-gitlab-domain.com