はじめに
こんにちは、GMOコネクト野口です。よろしくお願いします。
技術の向上には「アウトプット」がとても有効と聞きます。
時間をみつけて自分の知る情報を整理・発信していきます。
誰かの役に立つことがあれば幸いです。
この記事の対象者
- Gitを初めて学ぶ方
- Gitの基本的な用語や操作を理解したい方
- チーム開発でGitを使い始める方
なぜGitなのか
プロジェクトに参加する以上、ソース管理は必須です。
現在では、バージョン管理ツールとしてGitを採用しているプロジェクトがほとんどです。
当初は「初心者向けすぎる題材かな」と思っていましたが、現場で周りのメンバーにGitの理解度を聞いてみると、かなりばらつきがあることがわかりました。
確かに今はAIに聞けば一瞬で答えが得られる時代です。しかし、打ち合わせやコードレビューでは、Gitに関する用語は頻繁に出てきます。基本的な用語を理解していないと、コミュニケーションで困ることがあります。
そこで今回は、Gitの基本的な用語と基本動作を解説していきます。
環境
本記事では以下の環境を前提に解説します。
- OS: Windows
- リポジトリ: GitHub
- 操作方法: CLI（コマンドライン）
GitクライアントツールとしてはCLI、Visual Studio Code、TortoiseGitなどがよく使われますが、本記事ではCLIでの操作を中心に説明します。CLIを理解しておけば、他のツールでも応用が効きやすくなります。
① インストールと初期設定
1. Git for Windowsのダウンロード
公式サイトからインストーラーをダウンロードします。
- Git公式サイトにアクセス
- 「Download for Windows」ボタンをクリック
- インストーラー（exe形式）が自動でダウンロードされます。
2. インストール手順
ダウンロードしたインストーラーを実行します。
インストールウィザードが起動するので、ここでは全てデフォルト設定で進めてください。
3. インストールの確認
Git Bashまたはコマンドプロンプトを開いて、以下のコマンドを実行してください。
バージョン情報が表示されれば、インストール成功です。
git --version
# 出力例: git version 2.52.0.windows.1 (バージョン番号は時期により異なります)
4. 【重要】ユーザー名とメールアドレスの設定
Gitを使う前に、「誰が変更したか」を記録するための設定が必要です。これを行わないと、後述の「コミット」操作でエラーになります。
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
※ Your Nameにはローマ字の名前、you@example.comには自分のメールアドレスを入れて実行してください。
② Gitに関する用語解説
Gitと聞くと、「Git」「Git Bash」「GitHub」「GitLab」といった似た名前の用語をよく耳にすると思います。これらは全て異なるものを指しているので、まずはそれぞれの違いを解説します。
Git
Gitとは、ファイルの変更履歴を管理する仕組みそのものです。
プログラムを開発していると、「昨日のコードに戻したい」「誰がいつこの部分を変更したのか知りたい」といった場面に遭遇します。Gitはこうした問題を解決するために、ファイルの変更履歴を記録・管理してくれるツールです。
-
できること:
- ファイルの変更内容を記録する
- 過去のバージョンに戻す
- 誰がいつ何を変更したかを追跡する
- 複数人での開発を効率化する
①でインストールした「Git」がこれです。ローカル（自分のパソコン）で動作するバージョン管理システムとなります。
Git Bash
Git Bashとは、WindowsでGitを扱うためのコマンドライン環境です。
Windows標準のコマンドプロンプトとは異なり、Git Bashを使うことでLinuxやmacOSと同じようなコマンド操作が可能になります。
-
特徴:
- Windows上でLinux風のコマンドが使える
-
ls,cd,mkdirなどのLinuxコマンドも利用可能 - Git for Windowsをインストールすると自動的に付いてくる
GitHub
GitHubとは、Gitのデータをクラウド上に保存・共有できるサービスです。
Gitはローカルで履歴管理ができますが、チーム開発では他のメンバーとコードを共有する必要があります。GitHubを使うことで、クラウド上にコードを保存し、メンバー間で共有できるようになります。
-
主な機能:
- リモートリポジトリの提供（クラウド上にコードを保存）
- Pull Request（プルリクエスト）によるコードレビュー
- GitHub Actionsによる自動化（CI/CD）
GitLab
GitLabは、GitHubと同じようにコードを保存して共有できるサービスです。
さらに、タスク管理やテスト、自動でのデプロイなど、開発でよく使う作業をまとめて扱えるのが特徴です。
- GitHubとの用語の違い:
| 項目 | GitHub | GitLab |
|---|---|---|
| コードレビュー機能 | Pull Request (PR) | Merge Request (MR) |
| CI/CD (自動化) | GitHub Actions | GitLab CI/CD |
-
主な機能:
- 開発・テスト・デプロイまで一体で扱える
- CI/CD（自動テスト・自動ビルド）機能が標準で統合されている
- Merge Request（MR）という名前でコードレビューを行う
まとめ
それぞれの役割を整理すると以下のようになります。
- Git: ファイルの変更履歴を管理する仕組み
- Git Bash: WindowsでGitコマンドを使うための環境
- GitHub: Gitのデータをクラウドで共有するサービス
- GitLab: GitHubと同様のサービス + 開発全体の管理機能
③ Gitの基本用語
Gitは用語が多くて混乱しやすいですが、まずは この7つだけ 押さえればOK です。
1. リポジトリ（Repository）
リポジトリとは、プロジェクトの履歴が全部入った「保管場所」のことです。
プログラムのソースコードだけでなく、誰がいつどんな変更をしたかという履歴情報も全てリポジトリの中に保存されます。
（実際にはプロジェクトフォルダ内の .git という隠しフォルダに情報が詰まっています）
-
リポジトリの種類:
- ローカルリポジトリ: 自分のPC上にあるリポジトリ
- リモートリポジトリ: GitHub/GitLab上にあるリポジトリ（クラウド上）
2. コミット（Commit）
その時点のファイルの状態を保存します。「ここまでの作業が完了した」というタイミングでコミットを行います。
コミットには「何を変えたか」をメッセージで残すのがルールです。後から履歴を見たときに、何のための変更だったのかが分かるようにします。
コミットの流れ：
- ファイルを編集する
- git add: 変更したファイルを「ステージングエリア（買い物かご）」に入れる
- git commit: かごに入れたファイルを「リポジトリ（購入履歴）」に記録する
コマンド例：
# ファイルをステージングエリアに追加
git add file.txt
# コミットを実行（-m オプションでメッセージを指定）
git commit -m "初回コミット"
3. ブランチ（Branch）
ブランチとは、作業用の分岐のことです。
プロジェクトには通常mainという本番用のブランチがあります。新しい機能を追加したり、バグを修正したりする際は、別のブランチを作成して作業を行います。
なぜブランチを使うのか：
-
mainブランチを壊さずに安全に開発するため - 複数人で開発する際、それぞれが別のブランチで作業することで、お互いの作業が干渉しない
ブランチ名について：
※以前はmasterが標準ブランチ名でしたが、現在はmainが主流です。既存プロジェクトではmasterを使用している場合もあります。
コマンド例:
# 新しいブランチを作成
git branch feature-1
# 現在のブランチを確認
git branch
実行結果例:
* main
feature-1
※ *マークが付いているのが、現在作業中のブランチです。
※ git branchでブランチを作成しても、自動的には切り替わりません。作業を開始するにはgit checkout feature-1（またはgit switch feature-1）で切り替える必要があります。
4. マージ（Merge）
マージとは、ブランチの変更を別のブランチに統合する操作です。
例えば、feature ブランチで開発した機能を main ブランチに取り込むときに使います。
※実際のチーム開発では、GitHub上の「Pull Request」機能を使ってマージすることが一般的ですが、裏側ではこのマージ操作が行われています。（詳細は今後の記事で解説予定です）。
コマンド例:
# mainブランチに移動
git checkout main
# feature-1の内容を取り込む
git merge feature-1
5. プッシュ（Push）
プッシュとは、ローカルの変更をリモートリポジトリに送る操作です。
自分のPCで行った変更（コミット）を、GitHubやGitLabなどのリモートリポジトリに反映させます。
「自分の作業をクラウドに反映させる」イメージです。プッシュして初めて、他のメンバーが変更内容を見られるようになります。
コマンド例：
git push origin main
※originはリモートリポジトリの名前（デフォルトでこの名前になります）
※mainはプッシュするブランチ名です
【注意】
GitHubへのプッシュには認証が必要です。初回実行時にはブラウザでのログイン画面が表示されたり、トークンの設定が必要になる場合があります。
具体的には、GitHubでリポジトリを作成し、ローカルと紐づける設定が必要です（詳細は次回以降解説予定です）
6. フェッチ（Fetch）
フェッチとは、リモートの変更情報の確認です。
他のメンバーがリモートリポジトリに追加した変更を、「ダウンロードだけ」しておく状態になります。
自分の作業中のファイルは書き換わらないため、安全に最新状況を確認できます。
コマンド例:
git fetch origin
7. プル（Pull）
プルとは、リモートの変更を取り込み、自分の作業に反映する操作です。
実体は fetch（取得） + merge（統合） を同時に行っています。
チーム開発では、作業開始前に git pull して自分の手元を最新状態にするのが基本です。
コマンド例:
git pull origin main
まとめ：7つの用語の関係性
これらの用語がどのように関連しているかを図で表すと以下のようになります。
【ローカル】 【リモート（GitHub/GitLab）】
リポジトリ リポジトリ
↓ ↑
コミット ────────プッシュ─────→ コミット
↓ ↓
ブランチ ブランチ
↓ ↓
マージ ←────プル/フェッチ──── (他の人の変更)
基本的な作業の流れ:
- ブランチを作成して作業開始
- 変更をコミット（
add→commit） - リモートにプッシュ（
push） - GitHub上でPull Request / GitLabでMerge Requestを作成
- レビュー後、mainブランチにマージ
- 他のメンバーが
git pullして最新状態を取得
この7つの用語を理解していれば、Gitの基本的な操作はほぼカバーできます。
実際の開発現場で、製造担当・テスト担当としてアサインされている場合でも、リポジトリ・プル・プッシュ・コミット・マージあたりを理解していれば基本的なやり取りには困りません。
最後に
しばらくはGitについて書いていこうかと思います。
次回以降に書いていく内容を示しておきます。
- 7つの用語の動作を自分の環境で順番に試しながら実際の成果物を見ながらの解説
- これらを実際のプロジェクトで使っていく際、具体的にどのように活用できるのか
- Pull Request / Merge Requestの詳細解説、どんな時に使うのか・どのようなときに使うのか
いずれも現場目線の内容が書けるかと思います。
ここまで読んでいただき、ありがとうございました。