でも実は、Gitの基本操作は5~6個のコマンドを覚えれば、日々の作業の大半をこなせます。
この記事では、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へ接続・アップロードできる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ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で共有」でコンフリクト多発 | ブランチで並行作業→マージで統合 |
| 誰がいつ何を変えたか | 記憶と推測に頼る | git blame で1行単位で確認できる |
| AIツール連携 | 手動でファイルを貼り付け | GitHub Copilot等がリポジトリを直接参照 |
| 個人開発・副業プロジェクト | 「最終版.sh」「最終版2.sh」が乱立 | タグやブランチでバージョンを明確に管理 |
サーバー設定ファイルの管理、シェルスクリプトの開発、チームでの共同作業——すべての場面で役立ちます。
Linuxを実務で使うなら、Gitは「そのうち覚える」ではなく「今日から使う」べきスキルです。本記事では、5~10コマンドの範囲で実務に必要な操作を一通り押さえます。
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
$ sudo dnf install git -y
git --version でバージョンが表示されれば成功です。Gitは積極的に開発が続いているツールなので、ディストリ標準のバージョンが古い場合はバックポートリポジトリやPPAから最新版を入れる選択肢もあります。とはいえ、最初は標準パッケージで十分です。
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標準のLFを維持) $ git config --global core.autocrlf input # デフォルトブランチ名を main に統一(Git 2.28以降の推奨) $ git config --global init.defaultBranch main # pull時にrebaseではなくmergeを使う(初心者向けの安全な動作) $ git config --global pull.rebase false
init.defaultBranch main を設定しておくと、これから git init で作るリポジトリのデフォルトブランチが main になります。GitHubのデフォルトと揃うので必ず入れておきましょう。pull.rebase false は git pull 時の挙動を明示的に指定する設定です。指定しないと警告が出る場合があるため、最初は素直にmergeにしておくのが安全です。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のデータベースです。コミット履歴・ブランチ情報・設定など、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 <file>..." to include in what will be committed) README.md hello.sh nothing added to commit but untracked files present
git add で管理対象に追加します。# 特定ファイルをステージング $ git add README.md # ディレクトリ内の全ファイルをステージング $ git add . # 状態確認 $ git status On branch main No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: README.md new file: hello.sh
意図せず追加してしまった場合は
git restore --staged ファイル名 でステージングから外せます。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
コミットメッセージは「なぜこの変更をしたのか」を書くと後から読み返しやすくなります。1行目は50文字以内の要約、必要なら2行目以降に詳細を書く——これが慣習です。
直前のコミットメッセージを書き直したい、あるいはコミット直後に「ファイルを1つ入れ忘れた」と気付いた場合は
git commit --amend が便利です。# 直前のコミットにファイルを追加する $ git add 入れ忘れたファイル $ git commit --amend --no-edit # 直前のコミットメッセージだけ書き直す $ git commit --amend -m "正しいメッセージに修正"
--amend は「直前のコミットを別物に置き換える」操作なので、push済みのコミットには使わないでください。チーム履歴が壊れます。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} のように番号を指定します。退避内容にメモを付けたいときは git stash push -m "WIPメッセージ" が便利です。退避内容を戻さずに破棄したいときは
git stash drop stash@{0} を使います。変更を確認する3つのコマンド
1. 現在の状態を確認する(git status)
Gitを使う上で最も頻繁に実行するコマンドです。作業前後に必ず実行してください。
# ファイルを変更してから状態確認 $ echo "追記内容" >> README.md $ git status On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) modified: README.md
出力をコンパクトにしたい場合は
git status -s(short形式)を覚えておくと、状態確認が一目で済むようになります。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 オプションをつけないと何も表示されないので注意してください。「コミット後にどの行が変わったか」を後から確認したい場合は
git show コミットID で同じ形式の差分が出ます。2つのコミット間の差分を見たいときは git diff コミットID1..コミットID2 です。3. 変更履歴を確認する(git log)
これまでのコミット履歴を一覧で確認します。$ git log commit a1b2c3d4e5f6789012345678901234567890abcd Author: Tomohiro Miyazaki <tomohiro@example.com> 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 とシェルスクリプトを追加
a1b2c3d)を使って過去の状態を参照できます。--all オプションを付けると全ブランチの履歴が一覧で見られるため、現場ではよく使います。コミットメッセージをキーワードで絞り込みたい場合は
--grep オプションが便利です。「あの設定を変えたコミットはどれだっけ?」という場面で重宝します。# コミットメッセージに「nginx」を含む履歴だけを表示 $ git log --oneline --grep="nginx" c3d4e5f nginx設定ファイルのタイムアウト値を変更 b2c3d4e nginx.conf に gzip圧縮を追加 # 大文字小文字を区別しない検索(-i オプション) $ git log --oneline -i --grep="deploy" d4e5f6g Deployスクリプトを追加 # 期間で絞り込む(過去1週間分のコミットだけを表示) $ git log --oneline --since="1 week ago" # 特定の作者で絞り込む $ git log --oneline --author="Tomohiro"
--since・--until)や作者指定(--author)も覚えておくと、「先週誰が何を変えたか」を1コマンドで把握できます。チーム作業に入った瞬間から有用です。ファイルの1行ごとに「いつ・誰が・どのコミットで変更したか」を見たい場合は
git blame ファイル名 が便利です。サーバー設定ファイルでトラブルが起きたとき、「この行はいつ追加されたのか」を即座に特定できます。# ファイルの各行を、最後に変更したコミット情報とともに表示 $ git blame README.md a1b2c3d (Tomohiro Miyazaki 2026-05-03 10:00:00 +0900 1) # My Project b2c3d4e (Tomohiro Miyazaki 2026-05-04 11:30:00 +0900 2) 追記内容
.gitignoreでバージョン管理から除外する
すべてのファイルをGitで管理する必要はありません。以下のようなファイルは通常、バージョン管理から除外します。
・ログファイル(*.log)
・パスワードや秘密鍵(.env、id_rsa)
・OS固有のファイル(.DS_Store、Thumbs.db)
・一時ファイル(*.tmp、*.bak)
・ビルド生成物・依存ライブラリ(node_modules/、__pycache__/)
プロジェクトルートに
.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 は表示されない → 正しく除外されている
シェルスクリプトプロジェクトなら最初から
*.log・*.tmp を除外しておくのが定石です。すでにコミット済みのファイルを
.gitignore に追加しても、追跡対象から外れません。「ログファイルを誤ってコミットしてしまった」場合は次のように管理対象から外します。# 既に追跡されているファイルを追跡対象から外す(ファイル自体は残す) $ git rm --cached test.log $ git commit -m "test.logを追跡対象から除外"
# ホームディレクトリにグローバル.gitignoreを作成 $ cat ~/.gitignore_global .DS_Store *.swp *~ # 全リポジトリに適用するよう設定 $ git config --global core.excludesfile ~/.gitignore_global
.gitignore に書き足してもリポジトリ履歴には残り続けます。過去のコミットを掘れば誰でも読めてしまうので、認証情報を即座にローテーション(再発行)してください。GitHubにpush済みであれば、漏洩した前提で対応するのが鉄則です。GitHubへ接続してリモートリポジトリと連携する
ここまではローカルだけの管理でした。GitHubに接続すると、クラウド上にバックアップが作れ、別のマシンや複数人との共同作業が可能になります。
1. GitHubでリポジトリを新規作成する
GitHub(github.com)にログインして「New repository」からリポジトリを作成します。・リポジトリ名は英数字とハイフンで付ける
・「Initialize this repository with a README」は外したままにする(ローカルの内容を優先させるため)
・公開(Public)か非公開(Private)かを選択する。社内コードや個人的なメモは必ずPrivateにする
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
秘密鍵(.pub が付かない方)は絶対に他人へ送らないでください。Slackやメールに貼り付けるのも厳禁です。
# 3. 接続テスト $ ssh -T git@github.com Hi tomohiro! You've successfully authenticated, but GitHub does not provide shell access.
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 と命名します。登録URLを間違えた場合は
git remote set-url origin 正しいURL で上書きできます。リモートを削除したいときは git remote remove 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 で作業できます。リモート情報も origin として自動的に登録されているため、自分で git remote add する必要はありません。6. リモートの変更をローカルに取り込む(git pull)
チームで作業している場合や、別のPCでプッシュした変更をローカルに反映させたい場合はgit pull を使います。# リモートの最新状態を取り込む(fetch + merge を一括で行う) $ git pull origin main From git@github.com:your-username/myproject * branch main -> FETCH_HEAD Updating a1b2c3d..d4e5f6g Fast-forward README.md | 3 +++ 1 file changed, 3 insertions(+)
git pull は「git fetch(リモートの最新情報を取得)」と「git merge(ローカルブランチに統合)」を一度にまとめて実行するコマンドです。チームで作業する場合は、作業開始前に必ず
git pull を実行して最新の状態に揃えてから変更を加える習慣をつけてください。ブランチで作業を分ける(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
git switch -c ブランチ名 も同じ意味で使えますが、checkout -b もそのまま動作するので無理に切り替える必要はありません。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).
両方のブランチが変更された場合は「Merge commit」が作成されます。
チーム開発ではローカルで直接
git merge せず、GitHub上で「Pull Request(PR)」を作成してレビューを受けてからマージするのが標準です。個人開発でも、自分で書いた変更を時間を置いてレビューできる効果があるので、PRベースでの作業に慣れておくと得です。4. リリース時点を記録する(git tag)
「この時点を v1.0 としてリリースした」という節目を残したいときはgit tag を使います。シェルスクリプトの本番反映タイミングや、設定ファイルの「動作確認済みのバージョン」を明示するのに便利です。
# 現在のコミットにタグを付ける(注釈付きタグ -a が推奨) $ git tag -a v1.0 -m "v1.0: 初回リリース" # タグの一覧を確認 $ git tag v1.0 # タグをGitHubに送信(pushには別途指定が必要) $ git push origin v1.0
git checkout v1.0 でいつでも参照でき、「リリース時点に戻して動作確認」も簡単になります。過去の状態に戻す方法
Gitの最も重要な機能は「戻せること」です。1. まだコミットしていない変更を取り消す
# 変更を加えたファイルを元の状態に戻す $ git restore README.md # すべての未コミット変更を取り消す $ git restore . # ステージング(git add した状態)だけを取り消す $ git restore --staged README.md
git restore は変更を完全に取り消すため、実行後は元に戻せません。git diff で内容を確認してから使いましょう。2. 過去のコミットを参照する
# 特定コミット時点のファイルを確認(作業ディレクトリは変わらない) $ git show a1b2c3d:README.md # My Project # 過去の状態を一時的に確認する(デタッチドHEAD) $ git checkout a1b2c3d # 確認が終わったら元のブランチに戻る $ git checkout main
git checkout コミットID で過去の状態を見ているときは「デタッチドHEAD」と呼ばれる特殊な状態です。ここで作業してコミットしてもブランチに残らないので、確認だけにとどめてください。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 とシェルスクリプトを追加
4. ローカルのコミットを取り消す(git reset)
git reset は、まだGitHubにpushしていないローカルのコミットを取り消すコマンドです。push済みのコミットには使わないでください。チーム全員の履歴が壊れます。
# 直前のコミットを取り消す(変更内容はワークツリーに残す) $ git reset HEAD~1 Unstaged changes after reset: M README.md # 現在のコミット履歴を確認 $ git log --oneline a1b2c3d 最初のコミット: README とシェルスクリプトを追加 # 直前のコミットが消えて、変更がワークツリーに戻っている # 変更内容ごとすべて削除して取り消す(実行後は元に戻せない) $ git reset --hard HEAD~1
git reset HEAD~1(デフォルト: --mixed)は「コミットを取り消すが、変更ファイルは手元に残す」動作です。コミットメッセージを書き間違えたときや、まとめすぎたコミットを分割したいときに使います。
--hard は変更が完全に消えるため、実行前に git diff で内容を確認してください。万が一
--hard で大事な変更を消してしまった場合は git reflog を使うと過去のHEADの履歴が見られるので、そこからコミットIDを特定して復旧できます。完全に消えたわけではないので慌てず対処しましょう。# 過去のHEADの履歴を確認(resetで消したコミットも見える) $ git reflog a1b2c3d HEAD@{0}: reset: moving to HEAD~1 e5f6g7h HEAD@{1}: commit: 消してしまったコミット # コミットIDを指定して復旧 $ git reset --hard e5f6g7h
トラブルシュート・よくあるエラー対処
「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"
「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.
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.
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 がないファイル)は絶対に公開しないでください。
マージ時に「CONFLICT」が表示された場合
$ git merge feature/add-deploy-script Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.
コンフリクト状態のファイルを開くと、以下のようなマーカーが挿入されています。
<<<<<<< HEAD mainブランチ側の変更内容 ======= feature/add-deploy-scriptブランチ側の変更内容 >>>>>>> feature/add-deploy-script
<<<<<<・=======・>>>>>>)をすべて削除して正しい内容に書き直し、git add → git commit を実行するとコンフリクトが解消されます。# コンフリクトを手で解消した後 $ git add README.md $ git commit -m "コンフリクトを解消: README.md" [main e5f6g7h] コンフリクトを解消: README.md
git merge --abort でマージ前の状態に戻せます。「detected dubious ownership in repository」と表示された場合
WSL2でWindows側のディレクトリをGit管理しようとしたときや、別ユーザーが作成したディレクトリでGitコマンドを実行したときに出るエラーです。fatal: detected dubious ownership in repository at '/path/to/repo' To add an exception for this directory, call: git config --global --add safe.directory /path/to/repo
git config --global --add safe.directory パス を実行すれば解消します。WSL2環境では /mnt/c/ 配下を管理する場面でよく遭遇するので、覚えておくと便利です。本記事のまとめ
この記事では、LinuxでGitをはじめて使う方向けに基本操作を解説しました。| やりたいこと | コマンド |
|---|---|
| Gitの初期設定をする | git config --global user.name "名前" |
| リポジトリを初期化する | git init |
| ファイルをステージングに追加する | git add ファイル名 または git add . |
| 変更をコミットする | git commit -m "コミットメッセージ" |
| 直前のコミットを修正する | git commit --amend |
| 作業を一時退避する | git stash または git stash pop |
| 現在の状態を確認する | git status |
| 変更内容を確認する | git diff ファイル名 |
| ステージング済みの変更を確認する | git diff --staged ファイル名 |
| コミット履歴を確認する | git log --oneline |
| コミットメッセージをキーワードで検索する | git log --oneline --grep="キーワード" |
| 期間を指定して履歴を確認する | git log --oneline --since="1 week ago" |
| 1行ごとの変更者を確認する | git blame ファイル名 |
| ブランチを作成・切り替える | git checkout -b ブランチ名 |
| ブランチをマージする | git merge ブランチ名 |
| リリース時点にタグを付ける | git tag -a v1.0 -m "リリースメッセージ" |
| 未コミットの変更を取り消す | git restore ファイル名 |
| コミット済みの変更を安全に取り消す | git revert HEAD |
| ローカルのコミットを取り消す(push前限定) | git reset HEAD~1 |
| 消したコミットを復旧する | git reflog |
| ファイルを管理対象から除外する | .gitignore ファイルに記載する |
| 追跡済みファイルを管理対象から外す | git rm --cached ファイル名 |
| SSH鍵を生成する | ssh-keygen -t ed25519 -C "メールアドレス" |
| リモートリポジトリを登録する | git remote add origin URL |
| GitHubへ変更を送信する | git push -u origin main |
| リモートの変更を取り込む | git pull origin main |
| リポジトリをクローンする | git clone URL |
今日からシェルスクリプトや設定ファイルを
git init して管理する習慣をつけると、3ヶ月後には「Git以前にどうやって管理していたのか」と思うはずです。実務で使うLinuxスキル 7テーマ
・watchコマンドで定期的にコマンドを繰り返し実行する方法(シェルスクリプト)
・chmodコマンドで権限を変更する方法(セキュリティ)
・Apacheのタイムアウト設定を変更・確認する方法(サーバー構築)
・straceコマンドでプロセスのシステムコールを追跡する方法(トラブルシューティング)
・ncコマンドでネットワーク接続をテストする方法(ネットワーク)
・rsyncコマンドでファイルを同期・転送する方法(ファイルシステム・ストレージ)
・Linuxでポート番号の状態を確認するコマンド(現場コラム)
無料の「Linuxサーバー構築入門マニュアル(図解60ページ)」をプレゼントしています。
コマンドを「なんとなく打つ」段階から卒業したい方は、ぜひ受け取ってみてください。
無料マニュアルを受け取る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:クラウドシェルでLinuxコマンドを学ぶ方法|AWS・Googleのブラウザ環境で環境構築ゼロから始める入門ガイド
- 前のページへ:VirtualBoxでLinux仮想環境を構築する入門|Windowsでも安全に練習できる方法
- この記事の属するカテゴリ:【Linux入門】初心者のための基礎知識・講座へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます