LinuxでGitを使う入門|バージョン管理の基本と基本コマンドを初心者向けに解説

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)【Linux入門】初心者のための基礎知識・講座 > LinuxでGitを使う入門|バージョン管理の基本と基本コマンドを初心者向けに解説
「GitHubって何?」「バージョン管理って難しそう」——Linux初心者がこう感じるのは当然です。
でも実は、Gitの基本操作はコマンドが5つ覚えれば大半の作業をこなせます。

この記事では、LinuxでGitをはじめて使う人のために、インストールから基本コマンド、GitHubへの接続まで実際の作業フローを解説します。
対象環境: Ubuntu 24.04 LTS / Rocky Linux 9 / WSL2(Ubuntu)で動作確認済み。

この記事のポイント

・git init/add/commit の3ステップがGitの基本操作
・git status と git log でいつでも状態を確認できる
・git diff で変更内容を確認してからコミットする習慣が安全
・.gitignore でログや設定ファイルをバージョン管理から除外できる
・git remote add origin / git push でGitHubへ接続・アップロードできる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

なぜLinuxエンジニアにGitが必要なのか

サーバー管理をしていると、こんな状況に必ず直面します。

「/etc/nginx/nginx.conf を変更したら503が出た。元に戻したいが、どこを変えたか分からない」

設定ファイルを手で書き換えて、うまくいかなければ戻す——この作業を毎回「nginx.conf.bak1」「nginx.conf.old」のようなファイル名で管理している人は多いです。
でもこれ、3回目には何が最新か分からなくなります。

Gitはこの問題を根本から解決します。
変更のたびに「スナップショット」を記録し、いつでも過去の状態に戻せる仕組みです。

状況 Gitなし(従来の方法) Gitあり
設定ファイルの変更管理 nginx.conf.bak1、nginx.conf.old…と手動コピー git commit で自動記録、git log で履歴確認
問題発生時の切り戻し どのバックアップが正しいか不明 コミットIDを指定して即時復元
チーム共同作業 「最新ファイルをSlackで共有」でコンフリクト多発 ブランチで並行作業→マージで統合
AIツール連携 手動でファイルを貼り付け GitHub Copilot等がリポジトリを直接参照

サーバー設定ファイルの管理、シェルスクリプトの開発、チームでの共同作業——すべての場面で役立ちます。
Linuxを実務で使うなら、Gitは「そのうち覚える」ではなく「今日から使う」べきスキルです。

Gitをインストールする

1. インストール済みか確認する

まずは既にインストールされているか確認します。

# Gitのバージョン確認 $ git --version git version 2.43.0

バージョン番号が表示されればインストール済みです。
「command not found」と出た場合は次の手順でインストールします。

2. パッケージマネージャでインストールする

Ubuntu / Debian系(WSL2含む)の場合:

$ sudo apt update $ sudo apt install git -y

Rocky Linux / RHEL系の場合:

$ sudo dnf install git -y

インストール後に git --version でバージョンが表示されれば成功です。

3. 初期設定を行う(必須)

インストール直後に必ず行うべき設定が2つあります。
コミットに記録されるユーザー情報です。設定しないままコミットしようとするとエラーになります。

# ユーザー名の設定(自分の名前) $ git config --global user.name "Tomohiro Miyazaki" # メールアドレスの設定 $ git config --global user.email "tomohiro@example.com" # 設定の確認 $ git config --list user.name=Tomohiro Miyazaki user.email=tomohiro@example.com

--global はシステム全体への設定です。
プロジェクトごとに変えたい場合は --global を外してリポジトリ内で実行します。

エディタを指定しておくと git commit 時に使いやすくなります。

# コミットメッセージ編集をnanoにする場合 $ git config --global core.editor nano # vimにする場合 $ git config --global core.editor vim

Linux環境では改行コード変換のトラブルを防ぐために以下も設定しておくのが鉄則です。

# Linux環境での改行コード設定(Linux標準のLFを維持) $ git config --global core.autocrlf input

Gitの基本的な使い方(ローカルリポジトリ)

まず「ローカルリポジトリ」——自分のマシン上だけでGitを使う方法を覚えます。
GitHubへのアップロードはその後の話です。

1. リポジトリを初期化する(git init)

管理したいディレクトリに移動して、Gitリポジトリを作成します。

# 作業ディレクトリを作成して移動 $ mkdir ~/myproject $ cd ~/myproject # Gitリポジトリを初期化 $ git init Initialized empty Git repository in /home/tomohiro/myproject/.git/ # 隠しディレクトリ .git が作成される $ ls -la total 12 drwxr-xr-x 3 tomohiro tomohiro 4096 May 3 10:00 . drwxr-xr-x 12 tomohiro tomohiro 4096 May 3 10:00 .. drwxr-xr-x 7 tomohiro tomohiro 4096 May 3 10:00 .git

.git ディレクトリがGitのデータベースです。
これを削除するとバージョン管理がすべて消えるので絶対に削除しないでください。

2. ファイルをステージングに追加する(git add)

ファイルを作成して、Gitに「このファイルを次のコミットに含める」と伝えます。

# サンプルファイルを作成 $ echo "# My Project" > README.md $ echo "echo Hello, Linux!" > hello.sh # 現在の状態を確認 $ git status On branch main No commits yet Untracked files: (use "git add ..." to include in what will be committed) README.md hello.sh nothing added to commit but untracked files present

「Untracked files」はGitが管理していないファイルです。
git add で管理対象に追加します。

# 特定ファイルをステージング $ git add README.md # ディレクトリ内の全ファイルをステージング $ git add . # 状態確認 $ git status On branch main No commits yet Changes to be committed: (use "git rm --cached ..." to unstage) new file: README.md new file: hello.sh

「Changes to be committed」がステージング済みのファイルです。

3. コミットして変更を記録する(git commit)

ステージングした内容を「スナップショット」として確定します。

# コミット(メッセージは変更内容を簡潔に書く) $ git commit -m "最初のコミット: README とシェルスクリプトを追加" [main (root-commit) a1b2c3d] 最初のコミット: README とシェルスクリプトを追加 2 files changed, 2 insertions(+) create mode 100644 README.md create mode 100755 hello.sh

コミットが完了しました。このスナップショットにはいつでも戻れます。
コミットメッセージは「なぜこの変更をしたのか」を書くと後から読み返しやすくなります。

4. 作業を一時保存する(git stash)

「途中まで作業したが、急に別の修正対応が必要になった」——実務ではよく起こります。
git stash(スタッシュ)を使うと、コミットせずに作業中の変更を一時退避できます。

# 作業中のファイルがある状態を確認 $ git status On branch main Changes not staged for commit: modified: hello.sh # 変更を一時保存 $ git stash Saved working directory and index state WIP on main: a1b2c3d 最初のコミット # 作業ディレクトリがクリーンになった(退避完了) $ git status On branch main nothing to commit, working tree clean # 退避した変更を確認 $ git stash list stash@{0}: WIP on main: a1b2c3d 最初のコミット # 退避した変更を戻す $ git stash pop On branch main Changes not staged for commit: modified: hello.sh Dropped stash@{0}

git stash pop で退避内容を復元してリストから削除します。
複数の退避がある場合は git stash pop stash@{1} のように番号を指定します。

変更を確認する3つのコマンド

1. 現在の状態を確認する(git status)

Gitを使う上で最も頻繁に実行するコマンドです。
作業前後に必ず実行してください。

# ファイルを変更してから状態確認 $ echo "追記内容" >> README.md $ git status On branch main Changes not staged for commit: (use "git add ..." to update what will be committed) modified: README.md

「Changes not staged for commit」は変更済みだがコミット待ちのファイルです。

2. 変更内容を確認する(git diff)

何を変えたかを確認してからコミットするのが安全な運用の基本です。

# 変更内容を行単位で表示(まだステージングしていない変更) $ git diff README.md diff --git a/README.md b/README.md index 7e59600..8f3e4a1 100644 --- a/README.md +++ b/README.md @@ -1 +1,2 @@ # My Project +追記内容 # git add 後のステージング済みの変更を確認する場合 $ git add README.md $ git diff --staged README.md

「+」が追加行、「-」が削除行です。
git add した後は --staged オプションをつけないと何も表示されないので注意してください。

3. 変更履歴を確認する(git log)

これまでのコミット履歴を一覧で確認します。

$ git log commit a1b2c3d4e5f6789012345678901234567890abcd Author: Tomohiro Miyazaki Date: Sat May 3 10:00:00 2026 +0900 最初のコミット: README とシェルスクリプトを追加 # 1行で簡潔に表示する場合 $ git log --oneline a1b2c3d 最初のコミット: README とシェルスクリプトを追加 # ブランチの分岐をグラフで表示(チームでの実務でよく使う) $ git log --oneline --graph --all * b2c3d4e (feature/new-feature) 新機能を追加 * a1b2c3d (HEAD -> main) 最初のコミット # 特定ファイルの変更履歴だけを追う $ git log --oneline README.md a1b2c3d 最初のコミット: README とシェルスクリプトを追加

コミットIDの先頭7文字(例: a1b2c3d)を使って過去の状態を参照できます。
--all オプションを付けると全ブランチの履歴が一覧で見られるため、現場ではよく使います。

.gitignoreでバージョン管理から除外する

すべてのファイルをGitで管理する必要はありません。
以下のようなファイルは通常、バージョン管理から除外します。

・ログファイル(*.log)
・パスワードや秘密鍵(.env、id_rsa)
・OS固有のファイル(.DS_Store、Thumbs.db)
・一時ファイル(*.tmp、*.bak)

プロジェクトルートに .gitignore ファイルを作成して除外パターンを記載します。

# .gitignore ファイルの作成例 $ cat .gitignore # ログファイルを除外 *.log # 環境設定ファイルを除外(パスワード等) .env secrets.conf # バックアップファイルを除外 *.bak *.tmp # macOSのシステムファイル .DS_Store

# .gitignoreを確認して、除外されているか検証 $ touch test.log $ git status On branch main nothing to commit, working tree clean # test.log は表示されない → 正しく除外されている

言語やフレームワーク別の .gitignore テンプレートは GitHub公式(github.com/github/gitignore)で公開されています。
シェルスクリプトプロジェクトなら最初から *.log*.tmp を除外しておくのが定石です。

全プロジェクト共通で除外したいファイル(.DS_Store等)はグローバル設定にまとめると管理が楽になります。

# ホームディレクトリにグローバル.gitignoreを作成 $ cat ~/.gitignore_global .DS_Store *.swp *~ # 全リポジトリに適用するよう設定 $ git config --global core.excludesfile ~/.gitignore_global

GitHubへ接続してリモートリポジトリと連携する

ここまではローカルだけの管理でした。
GitHubに接続すると、クラウド上にバックアップが作れ、別のマシンや複数人との共同作業が可能になります。

1. GitHubでリポジトリを新規作成する

GitHub(github.com)にログインして「New repository」からリポジトリを作成します。
・リポジトリ名は英数字とハイフンで付ける
・「Initialize this repository with a README」は外したままにする(ローカルの内容を優先させるため)

2. SSH鍵でGitHubに接続する(推奨)

GitHubへの接続方法にはHTTPSとSSHの2種類があります。
実務ではSSH鍵認証(公開鍵暗号)を使うのが標準です。パスワード入力が不要になり、セキュリティも高くなります。

# 1. SSH鍵ペアを生成(ed25519形式が現在の推奨) $ ssh-keygen -t ed25519 -C "tomohiro@example.com" Generating public/private ed25519 key pair. Enter file in which to save the key (/home/tomohiro/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): [Enterキー or パスフレーズを入力] Your public key has been saved in /home/tomohiro/.ssh/id_ed25519.pub # 2. 公開鍵の内容を確認(GitHubに登録する内容) $ cat ~/.ssh/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx tomohiro@example.com

この公開鍵をGitHubの「Settings → SSH and GPG keys → New SSH key」に貼り付けます。

# 3. 接続テスト $ ssh -T git@github.com Hi tomohiro! You've successfully authenticated, but GitHub does not provide shell access.

「You've successfully authenticated」と表示されれば接続成功です。
SSH接続を使う場合はリモートURLを git@github.com:ユーザー名/リポジトリ名.git の形式にします。

3. リモートリポジトリを登録する(git remote add)

ローカルリポジトリにGitHubのURLを登録します。

# SSH方式(推奨) $ git remote add origin git@github.com:your-username/myproject.git # HTTPS方式(SSH設定が難しい場合) # git remote add origin https://github.com/your-username/myproject.git # 登録確認 $ git remote -v origin git@github.com:your-username/myproject.git (fetch) origin git@github.com:your-username/myproject.git (push)

origin はリモートリポジトリの「短縮名」です。慣習的に1つ目のリモートは origin と命名します。

4. ローカルの変更をGitHubへ送信する(git push)

# 初回pushは -u オプションで追跡設定(以降は git push だけでOK) $ git push -u origin main Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 271 bytes | 271.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To git@github.com:your-username/myproject.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'. # 2回目以降 $ git push

-u オプションは「このブランチはoriginのmainと紐づける」という意味です。
一度設定すれば次回から git push だけで送信できます。

5. GitHubのリポジトリをローカルに取得する(git clone)

他のマシンや別の人が作ったリポジトリを手元に持ってくる場合は git clone を使います。

# リポジトリをクローン(カレントディレクトリにmyprojectフォルダが作られる) $ git clone git@github.com:your-username/myproject.git Cloning into 'myproject'... remote: Enumerating objects: 3, done. remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. # クローンしたディレクトリに移動して作業開始 $ cd myproject $ git log --oneline a1b2c3d 最初のコミット: README とシェルスクリプトを追加

クローン後はそのまま git add/commit/push で作業できます。

ブランチで作業を分ける(git branch / merge)

「ブランチ」(branch)は、本番の安定したコードを守りながら新機能の開発や修正作業を行うための「作業の分岐」です。
Linuxの実務では「設定変更は必ずブランチを切ってから」が現場の鉄則です。

1. ブランチを作成・切り替える

# 現在のブランチを確認 $ git branch * main # 新しいブランチを作成して同時に切り替える(-b オプション) $ git checkout -b feature/add-deploy-script Switched to a new branch 'feature/add-deploy-script' # 現在のブランチを確認(* が現在地) $ git branch * feature/add-deploy-script main

2. ブランチで変更を加えてコミットする

# ブランチ上でファイルを追加・コミット $ echo "#!/bin/bash" > deploy.sh $ echo "rsync -avz ./ user@server:/var/www/html/" >> deploy.sh $ git add deploy.sh $ git commit -m "デプロイスクリプトを追加" [feature/add-deploy-script c3d4e5f] デプロイスクリプトを追加 1 file changed, 2 insertions(+) create mode 100755 deploy.sh

3. ブランチをメインに統合する(git merge)

# mainブランチに戻る $ git checkout main # feature ブランチをmainに統合 $ git merge feature/add-deploy-script Updating a1b2c3d..c3d4e5f Fast-forward deploy.sh | 2 ++ 1 file changed, 2 insertions(+) create mode 100755 deploy.sh # 統合済みブランチを削除(不要になったブランチは削除しておくのが定石) $ git branch -d feature/add-deploy-script Deleted branch feature/add-deploy-script (was c3d4e5f).

「Fast-forward」はメインブランチが動いていない場合に起こる最もシンプルなマージです。
両方のブランチが変更された場合は「Merge commit」が作成されます。

過去の状態に戻す方法

Gitの最も重要な機能は「戻せること」です。

1. まだコミットしていない変更を取り消す

# 変更を加えたファイルを元の状態に戻す $ git restore README.md # すべての未コミット変更を取り消す $ git restore .

git restore は変更を完全に取り消すため、実行後は元に戻せません。
git diff で内容を確認してから使いましょう。

2. 過去のコミットを参照する

# 特定コミット時点のファイルを確認(作業ディレクトリは変わらない) $ git show a1b2c3d:README.md # My Project # 過去の状態を一時的に確認する(デタッチドHEAD) $ git checkout a1b2c3d

3. コミット済みの変更を安全に取り消す(git revert)

コミット済みの変更を「なかったこと」にするには git revert が安全です。
「古いコミットを削除する」のではなく「打ち消すコミットを新たに追加する」ため、履歴が壊れません。
GitHubにpush済みのコミットを取り消す場合は必ずこちらを使います。

# 直前のコミットを取り消す(新しいコミットが追加される) $ git revert HEAD [main b2c3d4e] Revert "最初のコミット: README とシェルスクリプトを追加" 2 files changed, 2 deletions(-) # 特定のコミットIDを取り消す場合 $ git revert a1b2c3d # 確認 $ git log --oneline b2c3d4e Revert "最初のコミット: README とシェルスクリプトを追加" a1b2c3d 最初のコミット: README とシェルスクリプトを追加

トラブルシュート・よくあるエラー対処

「Please tell me who you are.」と表示された場合

*** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name"

初期設定が未完了です。「Gitをインストールする」セクションの手順3を実行してください。

「fatal: not a git repository」と表示された場合

$ git status fatal: not a git repository (or any of the parent directories): .git

git init を実行していないディレクトリでGitコマンドを実行した場合に出るエラーです。
ls -la.git ディレクトリがあるか確認し、なければ git init を実行してください。

「LF will be replaced by CRLF」という警告が出た場合

warning: LF will be replaced by CRLF in README.md.

WindowsとLinux間で改行コードが変換される際の警告です。
Linux環境では以下の設定でこの警告を防げます。

$ git config --global core.autocrlf input

「rejected: Updates were rejected」と表示された場合

$ git push ! [rejected] main -> main (fetch first) error: failed to push some refs to 'git@github.com:...' hint: Updates were rejected because the remote contains work that you do hint: not have locally. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again.

GitHub側のリポジトリに、ローカルにはない変更があるため拒否されています。
git pull でリモートの変更をローカルに取り込んでから再度 git push してください。

# リモートの変更を取り込む $ git pull origin main # コンフリクトがなければそのままpush可能 $ git push

SSH接続時に「Permission denied (publickey)」が出た場合

SSH鍵がGitHubに正しく登録されていない場合に出るエラーです。

# 鍵の登録状況を確認 $ ssh -T git@github.com git@github.com: Permission denied (publickey). # SSH鍵が存在するか確認 $ ls ~/.ssh/id_ed25519.pub /home/tomohiro/.ssh/id_ed25519.pub # 公開鍵の内容をGitHubに登録する $ cat ~/.ssh/id_ed25519.pub

公開鍵(.pub が付いたファイル)の内容をコピーして、GitHubのSSH設定画面に貼り付けてください。
秘密鍵(.pub がないファイル)は絶対に公開しないでください。

本記事のまとめ

この記事では、LinuxでGitをはじめて使う方向けに基本操作を解説しました。

やりたいこと コマンド
Gitの初期設定をする git config --global user.name "名前"
リポジトリを初期化する git init
ファイルをステージングに追加する git add ファイル名 または git add .
変更をコミットする git commit -m "コミットメッセージ"
作業を一時退避する git stash / git stash pop
現在の状態を確認する git status
変更内容を確認する git diff ファイル名
ステージング済みの変更を確認する git diff --staged ファイル名
コミット履歴を確認する git log --oneline
ブランチを作成・切り替える git checkout -b ブランチ名
ブランチをマージする git merge ブランチ名
未コミットの変更を取り消す git restore ファイル名
コミット済みの変更を安全に取り消す git revert HEAD
ファイルを管理対象から除外する .gitignore ファイルに記載する
SSH鍵を生成する ssh-keygen -t ed25519 -C "メールアドレス"
リモートリポジトリを登録する git remote add origin URL
GitHubへ変更を送信する git push -u origin main
リポジトリをクローンする git clone URL
リモートの変更を取り込む git pull origin main
Gitは「覚えてから使う」ツールではなく「使いながら覚える」ツールです。
今日からシェルスクリプトや設定ファイルを git init して管理する習慣をつけると、3ヶ月後には「Git以前にどうやって管理していたのか」と思うはずです。

実務で使うLinuxスキル 7テーマ
watchコマンドで定期的にコマンドを繰り返し実行する方法(シェルスクリプト)
chmodコマンドで権限を変更する方法(セキュリティ)
Apacheのタイムアウト設定を変更・確認する方法(サーバー構築)
straceコマンドでプロセスのシステムコールを追跡する方法(トラブルシューティング)
ncコマンドでネットワーク接続をテストする方法(ネットワーク)
rsyncコマンドでファイルを同期・転送する方法(ファイルシステム・ストレージ)
Linuxでポート番号の状態を確認するコマンド(現場コラム)

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
無料の「Linuxサーバー構築入門マニュアル(図解60ページ)」をプレゼントしています。
コマンドを「なんとなく打つ」段階から卒業したい方は、ぜひ受け取ってみてください。
無料マニュアルを受け取る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。