目次
GitHubコマンドとは？実務で使いこなすべき理由
GitHubの操作には、**GUI（グラフィカルユーザーインターフェース）とCLI（コマンドラインインターフェース）**の2つの方法があります。GitHub DesktopやSourceTreeなどのGUIツールは直感的で初心者に優しい一方、実務レベルのチーム開発では、CLIコマンドの習得が不可欠です。
CLIコマンドが実務で重視される理由は、再現性・自動化・トラブル対応力にあります。コマンドは文字列で記録できるため、手順の共有が容易で、属人化を防げます。また、複雑な操作やサーバー環境での作業では、CLIでなければ対応できない場面も多々あります。
GUIとCLIの使い分け
GUIツールの利点
- 視覚的にわかりやすく、ブランチ構造やコミット履歴をグラフィカルに表示
- マウス操作で完結し、学習コストが低い
CLIの利点
- キーボードだけで高速に操作でき、慣れれば圧倒的に効率的
- コマンド履歴が残るため、同じ操作を確実に再現可能
- スクリプト化して作業を自動化できる
- エラーメッセージが詳細で、問題の原因を特定しやすい
- SSH接続したサーバー環境でもスムーズに操作可能
実務では、日常的な確認作業はGUI、重要な操作や複雑な処理はCLIという使い分けが効果的です。
CLIコマンドが必須となる場面
1. チーム開発でのブランチ運用
複数人での並行開発では、ブランチの作成・切り替え・マージを頻繁に行います。git checkout -b feature/new-functionのように一行で新規ブランチを作成して切り替えられるため、作業効率が格段に向上します。
2. コンフリクト（競合）の解消
マージ時のコンフリクトでは、CLIが詳細なエラーメッセージを表示します。git statusで状態を確認し、git diffで差分を見ながら修正する流れは、GUIより正確に状況を把握できます。
3. コミット履歴の整理
プルリクエスト前のコミット履歴整理には、git rebase -iやgit commit --amendが必須です。これらはCLIでこそ真価を発揮します。
4. CI/CDパイプラインとの連携
自動テストや自動デプロイの設定では、必ずCLIコマンドを使用します。これらを理解し、カスタマイズするためにも、コマンドの知識は不可欠です。
5. リモート環境での作業
本番サーバーや開発サーバーにSSH接続して作業する際は、GUIツールが使えません。CLIコマンドの習得は、サーバー管理の前提条件となります。
本記事で扱うコマンドの範囲
本記事では、実務で頻繁に使用するGitコマンドを基本編・ブランチ操作編・応用編の3段階で解説します。
前提知識
- Gitの基本概念（リポジトリ、コミット、ブランチ）を理解している
- ターミナルの基本操作ができる
- GitHubアカウントを持ち、リポジトリ作成の経験がある
コマンドの範囲
- 基本編: リポジトリ準備、変更の記録、状態確認、リモート連携
- ブランチ操作編: ブランチの作成・切り替え・統合・削除
- 応用編: 変更の一時退避、履歴の整理、コミットの取り消し
各コマンドは基本構文 → 実務でよく使うオプション → つまずきやすいポイントの順で解説します。
【基本編】最初に覚えるべきGitHubコマンド
実務でGitを使う上で最初に習得すべきコマンドは、それほど多くありません。リポジトリの準備、変更の記録、状態の確認、リモートとの連携――この4つの操作をマスターすれば、日常的な開発作業の大半をこなせます。
リポジトリの準備｜git init / git clone
新規リポジトリの作成（git init）
git init
現在のディレクトリをGitリポジトリとして初期化します。実行すると.gitフォルダが作成され、Git管理が開始されます。
実務での使用例：
mkdir my-project
cd my-project
git init
既存リポジトリのコピー（git clone）
git clone [リポジトリURL]
GitHubなどのリモートリポジトリをローカル環境にコピーします。チーム開発参加時は、必ずこのコマンドから始めます。
git clone https://github.com/username/repository.git
cd repository
ディレクトリ名を指定することも可能です：
git clone https://github.com/username/repository.git my-project
注意点
git init実行前に、正しいディレクトリにいるか確認（pwdコマンドで確認）git cloneは自動的にディレクトリを作成するため、事前のディレクトリ作成は不要- プライベートリポジトリのクローンには、SSH鍵設定または認証情報が必要
変更を記録する｜git add / git commit
ファイルの変更をGitで記録するには、2段階のステップを踏みます。
ステージングエリアに追加（git add）
git add [ファイル名]
変更したファイルを「次のコミットに含める」という意思表示をします。
実務でよく使うパターン：
git add index.html # 特定ファイルを追加
git add index.html style.css # 複数ファイルを追加
git add . # すべての変更を追加
git add src/ # 特定ディレクトリ配下をすべて追加
変更を確定（git commit）
git commit -m "コミットメッセージ"
ステージングエリアの変更を履歴として確定します。コミットメッセージは必須です。
git add .
git commit -m "ユーザー登録機能を追加"
addとcommitを同時実行
git commit -am "修正内容"
-aオプションで追跡済みファイルの変更を自動的にステージングしてコミットできます。ただし、新規ファイルには適用されないため注意が必要です。
コミットメッセージのベストプラクティス
- 1行目：変更内容を50文字以内で簡潔に
- 2行目：空行
- 3行目以降：詳細な説明（必要な場合のみ）
実務でのメッセージ例：
git commit -m "feat: ユーザー登録APIを実装"
git commit -m "fix: ログイン時のバリデーションエラーを修正"
git commit -m "docs: READMEにセットアップ手順を追加"
状態を確認する｜git status / git log
現在の状態を確認（git status）
git status
現在のブランチ、ステージングエリアの状態、変更されたファイルを表示します。実務で最も頻繁に使うコマンドの一つです。
表示される情報：
- Changes to be committed: ステージング済み（次のコミットに含まれる）
- Changes not staged for commit: 変更されているがステージングされていない
- Untracked files: Gitで追跡されていない新規ファイル
実務での使用習慣：
git status # 作業前に現在の状態を確認
# ファイルを編集
git status # 変更内容を確認
git add .
git status # 再度確認
git commit -m "変更内容"
コミット履歴を確認（git log）
git log
過去のコミット履歴を時系列で表示します。
実務でよく使うオプション：
git log --oneline # 1行で簡潔に表示
git log -5 # 最新5件のみ表示
git log --oneline --graph --all # グラフ形式で表示
git log -- index.html # 特定ファイルの履歴のみ
git log --since="2024-01-01" # 特定期間のコミット
git log --author="Yamada" # 特定作成者のコミット
注意点
git log実行後はqキーで終了- ログが多い場合は
--onelineオプションを使用 - 具体的な変更内容は
git diffで確認
リモートと連携する｜git push / git pull
ローカルの変更をリモートに送信（git push）
git push origin [ブランチ名]
ローカルでコミットした変更をリモートリポジトリに反映させます。
git add .
git commit -m "新機能を追加"
git push origin main
初回のpush時は-uオプションを使用：
git push -u origin main
これにより、次回以降はgit pushだけで同じブランチにプッシュできます。
リモートの変更をローカルに取り込む（git pull）
git pull origin [ブランチ名]
リモートリポジトリの最新変更をローカルに取り込みます。チーム開発では、作業開始前に必ず実行する習慣をつけましょう。
実務での使用習慣：
git pull origin main # 朝の作業開始時
# 自分の作業
git add .
git commit -m "作業内容"
git pull origin main # プッシュ前に最新状態を確認
git push origin main
pullとfetchの違い
- git pull: リモートの変更を取得して自動的にマージ
- git fetch: リモートの変更を取得するだけ（マージはしない）
安全性を重視する場合はfetchを使用：
git fetch origin
git merge origin/main
プッシュ前の確認チェックリスト
git status # 変更が正しくコミットされているか
git log -1 # 最新のコミットメッセージを確認
git pull origin main # 最新状態を取得
git push origin main # プッシュ
【ブランチ操作編】チーム開発で必須のコマンド
チーム開発において、ブランチ操作は最も重要なスキルです。複数人が同時に開発を進める際、メインブランチを直接編集せず、機能ごとに別ブランチを作成して作業します。これにより、他メンバーの作業に影響を与えず、安全に開発を進められます。
ブランチを作成・切り替える｜git branch / git checkout / git switch
ブランチの確認と作成（git branch）
git branch # 現在のブランチ一覧を表示
git branch feature/login # 新しいブランチを作成（切り替えはしない）
git branch -a # リモートも含めたすべてのブランチを表示
実務では、ブランチ名にプレフィックスを付けるのが一般的です：
feature/: 新機能の開発fix/: バグ修正hotfix/: 緊急の修正release/: リリース準備
ブランチの切り替え（git checkout / git switch）
従来の方法：
git checkout feature/login # 既存ブランチに切り替え
git checkout -b feature/new-function # 新規ブランチを作成して切り替え
新しい方法（Git 2.23以降推奨）：
git switch feature/login # 既存ブランチに切り替え
git switch -c feature/new-function # 新規ブランチを作成して切り替え
git switch - # 直前のブランチに戻る
checkoutとswitchの使い分け
- git switch: ブランチ切り替え専用（役割が明確）
- git checkout: 多機能だが混乱しやすい
新規プロジェクトではgit switchの使用を推奨します。
実務での典型的な作業フロー
git switch main
git pull origin main
git switch -c feature/user-profile
# 開発作業
git add .
git commit -m "ユーザープロフィール画面を実装"
git push -u origin feature/user-profile
注意点
- ブランチ切り替え前に、変更をコミットまたはstashする必要がある
- ブランチ名を間違えると新しいブランチが作成される
- リモートブランチに切り替える際は、まず
git fetchで最新情報を取得
変更を統合する｜git merge
開発完了後、ブランチの変更をメインブランチに統合するのがgit mergeです。
基本的なマージ操作
git switch main # マージ先のブランチに切り替え
git pull origin main # 最新状態に更新
git merge feature/login # マージ元のブランチを統合
マージの種類
- Fast-forward merge（早送りマージ）: ブランチが一直線の場合、単純にポインタを進める
- 3-way merge（三方向マージ）: 両方のブランチに新しいコミットがある場合、マージコミットを作成
実務での使い分け：
git merge --ff-only feature/login # Fast-forwardマージを強制
git merge --no-ff feature/login # 必ずマージコミットを作成
マージコンフリクト（競合）への対処
git merge feature/login
# CONFLICT (content): Merge conflict in index.html
git status # コンフリクトが発生したファイルを確認
# ファイルを開いて手動で修正
# <<<<<<< HEAD（自分の変更）
# =======（相手の変更）
# >>>>>>> feature/login
git add index.html
git commit -m "コンフリクトを解決"
実務でのコンフリクト対処のコツ
- コンフリクト発生時は、まず変更内容を相手に確認
- 安易に自分の変更を優先せず、両方の意図を理解してから統合
- 解決後は必ず動作確認を実施
マージを取り消す
git merge --abort # マージ前の状態に戻す
ブランチを削除する｜git branch -d
作業完了後、マージ済みのブランチは削除して整理します。
ローカルブランチの削除
git branch -d feature/login # マージ済みブランチを削除
git branch -D feature/login # 強制削除
-dは安全な削除方法で、マージされていないブランチは削除できません。-Dは強制削除なので、本当に不要か確認してから実行しましょう。
リモートブランチの削除
git push origin --delete feature/login
実務での削除フロー
git switch main
git branch -d feature/login
git push origin --delete feature/login
git fetch --prune # リモートで削除されたブランチ情報をローカルからも削除
【応用編】実務で差がつく便利なコマンド
変更を一時退避する｜git stash
作業中に別の緊急対応が入った場合など、現在の変更を一時的に退避できます。
git stash # 現在の変更を退避
git stash list # 退避した変更の一覧
git stash pop # 最新の退避を復元して削除
git stash apply # 最新の退避を復元（削除しない）
git stash drop # 最新の退避を削除
実務での使用例：
# feature/loginで作業中
git stash # 変更を退避
git switch main # mainブランチに切り替え
# 緊急対応
git switch feature/login # 元のブランチに戻る
git stash pop # 作業を復元
コミット履歴を整える｜git rebase / git commit –amend
直前のコミットを修正（git commit –amend）
git commit --amend -m "正しいコミットメッセージ" # メッセージのみ修正
git add 忘れてたファイル.txt
git commit --amend --no-edit # ファイルを追加
複数のコミットを整理（git rebase）
git rebase -i HEAD~3 # 直近3件のコミットを編集
# エディタで "pick" を "edit" や "squash" に変更
注意点
- リモートにプッシュ済みのコミットは原則修正しない（他メンバーに影響）
- 必要な場合はチームに周知してから
git push --force
特定のコミットを取り消す｜git revert / git reset
コミットを取り消す（git reset）
git reset --soft HEAD^ # コミットのみ取り消す（変更は残る）
git reset HEAD^ # コミットとステージングを取り消す
git reset --hard HEAD^ # コミットも変更も完全に削除（注意！）
安全にコミットを打ち消す（git revert）
git revert [コミットID] # 指定コミットを打ち消す新しいコミットを作成
git revertは履歴を残すため、リモートにプッシュ済みのコミットを取り消す際に推奨されます。
差分を確認する｜git diff
git diff # ステージング前の変更を表示
git diff --staged # ステージング済みの変更を表示
git diff main feature/login # ブランチ間の差分を表示
git diff HEAD~3 HEAD # 3つ前のコミットとの差分
実務でよくある操作パターン
新機能開発を始めるときの流れ
git switch main
git pull origin main
git switch -c feature/user-profile
# 開発作業
git add .
git commit -m "ユーザープロフィール画面の基本レイアウトを実装"
git push origin feature/user-profile
ポイント
- 必ずmainを最新にしてからブランチを作成
- ブランチ名は命名規則を統一（
feature/機能名など） - 1日の終わりには必ずリモートにプッシュ
他のメンバーの変更を取り込むとき
方法1：merge を使う（推奨・初心者向け）
git add .
git commit -m "作業中の変更を保存"
git switch main
git pull origin main
git switch feature/user-profile
git merge main
方法2：rebase を使う（履歴を綺麗に保ちたい場合）
git add .
git commit -m "作業中の変更を保存"
git fetch origin
git rebase origin/main
# コンフリクトがあれば解決
git add .
git rebase --continue
mergeとrebaseの使い分け
- merge: 操作が安全で初心者向け
- rebase: 履歴が一直線で綺麗だが、操作ミスのリスクあり
チームで方針を統一することが重要です。
間違えてコミットしてしまったとき
ケース1：直前のコミットメッセージを修正
git commit --amend -m "正しいコミットメッセージ"
ケース2：直前のコミットにファイルを追加
git add 忘れてたファイル.txt
git commit --amend --no-edit
ケース3：直前のコミットを取り消す
git reset --soft HEAD^ # 推奨：変更内容は残す
git reset --hard HEAD^ # 注意：変更も完全に削除
GitHubコマンドで困ったときの対処法
よくあるエラーと解決方法
1. Permission denied (publickey)
SSH接続の認証失敗です。
# HTTPS接続に切り替える
git remote set-url origin https://github.com/ユーザー名/リポジトリ名.git
# SSH接続のテスト
ssh -T git@github.com
2. Merge conflict（マージコンフリクト）
git status # コンフリクトファイルを確認
# ファイルを手動で修正
git add index.html
git commit -m "コンフリクトを解決"
3. Your branch is behind ‘origin/main’
git pull origin main # リモートの変更を取り込む
4. Failed to push some refs
git pull origin main # リモートの変更を取り込む
# コンフリクトがあれば解決
git push origin main
コマンド実行前の確認習慣
基本チェックリスト
git branch # 現在のブランチを確認
git status # 作業ディレクトリの状態を確認
git fetch origin
git status # リモートとの差分を確認
git statusを習慣化する重要性
git statusは現在の状態を把握するための最重要コマンドです。コマンド実行前後に必ず実行する癖をつけましょう。
困ったときに調べる方法
公式ドキュメント
- Git公式ドキュメント：https://git-scm.com/doc
- GitHub公式ドキュメント：https://docs.github.com/ja
コマンドラインでヘルプ表示
git help コマンド名
git help commit
効果的な検索方法
"Permission denied (publickey)" GitHub
"マージコンフリクト" 解決方法 Git
チーム内で質問しやすい環境づくり
- Slackなどに「Git質問チャンネル」を作る
- 過去の質問と回答をドキュメント化
- 「分からないことは恥ずかしくない」という文化を作る
GitHubコマンドを活用したチーム開発の効率化
コマンド操作の標準化が属人化を防ぐ
「この作業は〇〇さんしかできない」という状態は、チームにとって大きなリスクです。GitHubコマンドの使い方を標準化することで、誰でも同じ品質で作業できる体制を構築しましょう。
標準化すべき項目
ブランチ命名規則
feature/機能名 # 新機能開発
fix/バグ内容 # バグ修正
refactor/対象 # リファクタリング
docs/内容 # ドキュメント修正
コミットメッセージのフォーマット
[add] ユーザープロフィール画面を追加
[fix] ログイン時のエラーハンドリングを修正
[update] 顧客管理APIのレスポンス形式を変更
基本的な作業フロー
# 毎日の作業開始時
git switch main
git pull origin main
git switch 作業ブランチ
# 作業終了時
git add .
git commit -m "コミットメッセージ"
git push origin 作業ブランチ
社内ドキュメントに残すべき内容
- よく使うコマンド一覧
- シーン別の操作手順
- エラー発生時の対処法
- 質問先・相談先
小さなチームこそ、基本を押さえた運用が大切
小規模チームでも実践できる基本ルール：
1. 毎日のプルリクエスト文化
- どんなに小さな変更でもプルリクエストを作成
- 最低1人のレビューを必須に
- コードレビューは学び合いの場として捉える
2. ブランチ運用のシンプル化
- mainブランチ + 作業ブランチのシンプルな構成
- 作業ブランチは、マージ後すぐに削除
3. 定期的な振り返り
- 週1回、15分程度の「Git運用の振り返り」を実施
- 困ったことや改善したいことを共有
- ルールは柔軟に見直す
Harmonic Societyが考える「ちょうどいい仕組みづくり」
私たちHarmonic Societyは、中小企業にとって「ちょうどいい」デジタル化を支援しています。GitHubの運用も同じです。大企業向けの複雑な運用ではなく、御社の規模や開発体制に合った、無理なく続けられる仕組みを一緒に考えます。
Harmonic Societyが提供できる支援
1. チーム開発の体制構築
- 現状の開発フローをヒアリングし、課題を整理
- チームの規模やスキルレベルに合わせたGit運用ルールの策定
- 社内ドキュメント・マニュアルの作成支援
2. 実務に即した教育・レクチャー
- 実際のプロジェクトを使ったハンズオン形式
- よくあるトラブルと対処法を実例をもとに解説
- 質問しやすい環境づくりのサポート
3. 開発環境の整備
- GitHubだけでなく、CI/CDやコードレビューツールの導入支援
- 過度に複雑にせず、必要最小限の構成で効率化
- 運用開始後のフォローアップ
こんなお悩みはありませんか？
- Gitを導入したいが、何から始めればいいか分からない
- 今の運用が属人化していて、標準化したい
- エラーが出たときに対処できるメンバーが限られている
もし一つでも当てはまるなら、ぜひ一度ご相談ください。御社の状況に合わせた「ちょうどいい」Git運用を、一緒に考えさせていただきます。
お問い合わせ
Harmonic Society株式会社
https://harmonic-society.co.jp/contact/
まとめ｜GitHubコマンドで開発をもっとスムーズに
本記事では、GitHubコマンドの基本から実務での応用まで、チーム開発で本当に使える知識を解説しました。
記事の要点
- 基本コマンド（clone、add、commit、push、pull）の正しい理解が第一歩
- ブランチ操作を使いこなすことで、複数人での並行開発がスムーズに
- 実務でのシーン別パターンを覚えれば、迷わず作業を進められる
- エラーへの対処法を知っていれば、トラブル時も冷静に対応可能
- 標準化とドキュメント化が、属人化を防ぎチーム全体の効率を高める
GitHubコマンドは、最初は難しく感じるかもしれません。しかし、基本を押さえて実務で繰り返し使っていくうちに、自然と身についていきます。
大切なのは、完璧を目指すことではなく、チーム全員が安心して使える「ちょうどいい」運用を見つけることです。本記事が、あなたのチーム開発をより快適にする一助となれば幸いです。
