LinuxにGitを導入するには、サポート中のOSと配布元を選び、導入後の実体/版・作者情報・認証を分けて確認します。TLSの証明書検証停止や平文保存を通常手順にしません。

元のコード16ブロックは保持しています。旧コマンドの誤り・危険な操作は各ブロックの直前で区別しているため、コードだけをまとめて実行しないでください。

この記事の要点

Ubuntu/Debianはapt、対応するRHEL系はdnf等、まず対象OSの保守された配布元を確認。Archの部分更新は避ける 追加配布元/ソースビルドは必要機能と保守責任から判断。IUSは保守終了済みで、新規導入先として推奨しない 作者名/メールはcommitの記録。global設定やmainへの統一を、導入・cloneに必須としない 認証方法は接続先ごとに確認。TLS検証を維持し、個人PCでもcredentialの平文保存を一律に勧めない Gitの版・配布パッケージの更新・必要機能を別々に確認。2.40以上という数字だけでは安全性を保証しない

パッケージマネージャでインストール

対象OSがサポート中かを確認し、まず配布元のパッケージを検討します。上流版より数字が古くても修正がbackportされる場合があり、版だけで未修正と判定しません。逆に、公式配布でも全パッケージが同じ期間/範囲で保守されるとは限りません。以下は各方式の例で、一括実行する手順ではありません:

Ubuntu / Debian

次のapt例はDebian/Ubuntu系向けです。対象OSと有効repoを確認し、実行するとパッケージ情報/導入状態が変わります。-yで内容確認を省略する前に依存や変更範囲を確認し、表示版は旧例で現在の提供版ではありません。

sudo apt update
sudo apt install -y git

git --version
# git version 2.43.0 など

CentOS / RHEL / Rocky / AlmaLinux

次のCentOS 7用yumを新規サーバーの手順として実行しません。RHEL/Rocky/AlmaLinux等もOS版・サポートと有効repoを個別に確認します。コマンドの存在と保守中であることは別です。

# RHEL 8 / 9 系
sudo dnf install -y git

# CentOS 7 系（古い、yum）
sudo yum install -y git

git --version

Fedora

次のFedora例も対象releaseのサポートと提供パッケージを確認して利用します。dnfを使うことは常に上流最新版が入る保証ではありません。

sudo dnf install -y git
# Fedora は dnf がデフォルト、比較的新しい git が入る

Arch / Manjaro

次の旧pacman -Sy gitは実行しないでください。ArchではDB同期だけ行って一部だけ更新する部分更新は非対応です。Archの更新案内と手動介入事項を確認したうえで、必要ならsudo pacman -Syu gitのように全体更新と導入を行います。これはGitだけでなくシステム全体を更新する操作です。Manjaroは別配布元として自身の手順を確認します。

sudo pacman -Sy git
# Arch は常にローリングリリースで最新

openSUSE

次のzypperはopenSUSEの対象版/有効repoに合う場合の導入例です。他のOSのコマンドを混ぜず、-yによる自動承認前に変更内容を確認します。

sudo zypper install -y git

Alpine

次のapkはAlpine向けです。コンテナ内の導入は通常そのコンテナの書込層に限られ、ホストのGit更新ではありません。恒久的なイメージ変更はDockerfile等で管理し、本番コンテナを直接変更して済ませないでください。

sudo apk add git
# Docker の Alpine ベースイメージで頻出

最新版を入れたい場合

Ubuntu: git-core PPA

PPAはGit公式のLinux導入案内にも掲載されていますが、OS標準配布とは別の更新元を追加する判断です。必要機能・対象Ubuntu版・管理方針・更新/復旧を確認してから選びます。固定の遅延期間や、下の旧出力にある2.45.xを現在の最新版と扱いません:

次のPPA追加は標準パッケージの確認とは別の設定変更です。対応OS・管理者承認・更新/復旧を確認してから検討し、旧出力にある固定版を現在の最新版としないでください。

sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install -y git

git --version
# git version 2.45.x 等の最新が入る

RHEL / Rocky: IUS リポジトリ

IUS公式は保守終了と、このsetup手順が動かないことを案内しています。次のius-release-el8.rpm/git236は現行導入例として実行しません。URLやvaultの存在を保守継続の証明にせず、EPELとIUSも別の配布元として扱います。

# EPEL + IUS 追加
sudo dnf install -y epel-release
sudo dnf install -y https://repo.ius.io/ius-release-el8.rpm

sudo dnf install -y git236   # git 2.36 系を入れる例

ソースからビルド（最新を必ず）

見出しの「最新を必ず」は保証ではありません。下はv2.45.0固定の旧ビルド例で、現在の最新版や修正済み版を指しません。各OSの依存リストは同一ではなく、configure/makeや各開発ツールの要否も対象版のINSTALLで確認します。公式配布物と署名等を確認し、展開・ビルドは一般ユーザーの専用作業先で行います。sudo make installは/usr/local等を変更し、既存のPATH/パッケージと競合するので確認作業として実行しません。ソース導入後の更新責任も必要です。

# 依存パッケージ
# Ubuntu
sudo apt install -y dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
    gettext libz-dev libssl-dev install-info

# RHEL
sudo dnf install -y dh-autoreconf curl-devel expat-devel gettext-devel \
    openssl-devel perl-devel zlib-devel

# ソース取得
wget https://github.com/git/git/archive/refs/tags/v2.45.0.tar.gz
tar xzf v2.45.0.tar.gz
cd git-2.45.0

# ビルド
make configure
./configure --prefix=/usr/local
make all -j$(nproc)
sudo make install

git --version
# git version 2.45.0
which git
# /usr/local/bin/git

インストール直後の初期設定

commitには作者情報が必要ですが、既存設定や推測値が使われる場合もあります。意図した名前/公開してよいメールかを確認し、プロジェクト別には--localを選びます。cloneだけのために作者情報を登録する必要はありません:

次のglobal設定を一括投入しません。作者情報と認証を分け、init.defaultBranchは新規init用、pull.rebaseは履歴処理方針、editorは実際の環境、push.autoSetupRemoteは対応Git版と運用に依存します。globalは他のリポジトリにも影響します。listやcatの結果には秘密値/内部URL等が含まれることがあるため、そのまま公開しません。

# 必須2項目
git config --global user.name  "Yamada Taro"
git config --global user.email "taro@example.com"

# モダン推奨設定
git config --global init.defaultBranch main           # init 時 main を使用
git config --global pull.rebase true                  # pull は rebase 動作
git config --global core.editor "vim"                 # コミットメッセージエディタ
git config --global color.ui auto                     # 色付き出力
git config --global push.autoSetupRemote true         # 新ブランチを自動 upstream

# 設定確認
git config --global --list
cat ~/.gitconfig

認証の設定

HTTPS + Personal Access Token (PAT)

GitHub.comのHTTPS認証ではアカウントのパスワードを使いません。ただしPATの手入力だけが唯一の方式ではなく、GitHub CLIやGit Credential Manager等の方式もあります。認証不要の公開cloneと、認証が必要な操作を区別します:

次は旧認証方式の列挙で、全行を実行する設定手順ではありません。PATを使うなら可能な用途ではfine-grainedと必要最小の対象/権限・有効期限を検討し、repo/workflowを無条件に付けません。credential.helper storeは平文保存で、個人PCなら安全という例外はありません。cacheはメモリ内の一時保存で恒久保存ではなく、86400秒が全員に適切とも限りません。OSの安全な保存先と連携するhelper等を検討し、libsecretの固定パスやmacOS用helperがLinuxに必ず存在するとは扱いません。トークンをURL/引数/履歴/記事へ書きません。

# GitHub: Settings → Developer settings → Personal access tokens (classic)
# → Generate new token → repo / workflow スコープ選択
# → 表示されたトークン文字列をコピー (例: ghp_xxxxxxxxxxxx)

# クローン時に input
git clone https://github.com/user/repo.git
# Username: user
# Password: ghp_xxxxxxxxxxxx   ← PAT を入力

# 毎回入力は面倒なので Credential Helper を有効化
git config --global credential.helper cache             # 一時キャッシュ
git config --global credential.helper "cache --timeout=86400"

# 永続保存（平文、個人 PC のみ）
git config --global credential.helper store

# Gnome キーリング / KDE Wallet 連携
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

# macOS Keychain
git config --global credential.helper osxkeychain

SSH 鍵認証

次の鍵生成は既存の~/.ssh/id_ed25519を上書きしないことを先に確認します。公開鍵だけを登録し秘密鍵は渡しません。agentの起動/選択は環境ごとに確認し、既存agentを闇雲に増やさないでください。初回のホスト鍵指紋は公式情報で照合し、接続先検証を停止しません。GitHubのssh -Tは認証成功時も終了コード1になる仕様で、終了コードだけで失敗と扱いません。認証成功と対象repoの権限も別です。

# 鍵生成（Ed25519 推奨）
ssh-keygen -t ed25519 -C "taro@example.com"
# → ~/.ssh/id_ed25519 / id_ed25519.pub

# パスフレーズは付けるべき
# ssh-agent でセッション中はパスフレーズ省略
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# 公開鍵を 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, ...

# SSH 形式 URL でクローン
git clone git@github.com:user/repo.git

主要ディストロでの git バージョン比較

ディストロ	標準リポの git	最新版を入れる方法
Ubuntu 24.04 LTS	有効な配布元と更新版をapt-cache policy gitで確認	PPA追加は必要性と保守方針から判断
Ubuntu 22.04 LTS	OS/パッケージのサポート範囲と更新版を確認	上流版の数字だけで未修正と判断しない
Debian 12	有効なsuite・保守期間と配布版を確認	backportsの対象/保守条件と必要機能を確認
RHEL 9 / Rocky 9	OS版/有効repo・dnf info gitで確認	IUSは現行の選択肢にしない
RHEL 8 / Rocky 8	有効repo/配布元の提供内容を確認	git:2.xという仮のstream名を有効化しない
CentOS 7	CentOS Linux 7はサポート終了	Git単体の差替えでなくOS移行を計画
Fedora 40+（元記事の表記）	現在サポート中のreleaseと提供版を確認	40以上なら全て保守中/常に上流最新とはしない
Arch / Manjaro	各配布元のrepo・更新案内を確認	Archの部分更新は非対応。Manjaroも自身の更新手順を確認
Alpine	release/有効repoとapk policy gitで確認	apk upgradeはGitだけの確認ではなく更新操作

動作確認

次の旧例の~/git-testは既存なら再利用せず、新しい隔離先を使います。echoの上書きやgit add .への秘密情報混入に注意し、commit前に作者/対象ファイルを確認します。Git本体の動作確認にGitHubの大きなリポジトリをcloneすることは必須ではありません。ネットワークなしの実行例は下の関連記事へ分離しています。

# バージョン
git --version

# 動作テスト
mkdir ~/git-test && cd ~/git-test
git init
echo "hello" > README.md
git add .
git commit -m "Initial commit"
git log

# 設定確認
git config --list
git config --get user.email

# 既存リポジトリのクローン（公開リポで認証無し）
git clone https://github.com/git/git.git

古い CentOS 7 で git 1.8 を使う場合の注意

CentOS Linux 7は2024年6月30日にサポート終了しました。GitHubのアカウントパスワード廃止と、HTTPSでのトークン等による認証は別の話で、「古いGitではBasic認証が全て使えない」と一括りにしません。ただし旧Git/暗号ライブラリの互換性とOSの保守は必要で、Gitだけを入れ替えて終了済OSを安全とは扱いません。対応方針を個別に検討します:

• 移行先OSの現在のサポート・対応アプリ/依存・データと復旧計画を確認する。固定の旧OS版への移行を一律に勧めない
• IUSは保守終了済み。vaultに履歴があっても現行の保守配布と扱わず、新規導入策にしない
• ソースビルドは必要時だけ、修正/更新を自ら管理できる前提で検討。2.40以上という条件だけで採用しない
• コンテナを使う場合もホストOS/カーネル・マウント・イメージ更新と権限を確認。終了済ホストの保守問題は解消しない

トラブル

git: command not found

次のwhichの終了値や表示パスを決め打ちしません。まずcommand -v git等で今使うシェルの実体を調べます。~/.bashrcへの追記/sourceは設定変更と実行であり、診断の一部として一括実行しません。shell/ログイン方式・複数のGit/WSL/IDEを区別します。

# パッケージインストール忘れ
which git
echo $?         # 1 が返る

# パス確認
echo $PATH

# ソースから入れた場合 /usr/local/bin がパスに無い
echo 'export PATH="/usr/local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

SSL 証明書エラー

fatal: unable to access 'https://github.com/...':
SSL certificate problem: unable to get local issuer certificate

次のhttp.sslVerify falseは暫定回避としても勧めません。HTTPSの相手の証明書検証を全体で停止し、なりすましを検出できなくなるためです。ca-certificatesの導入/更新はOS依存の変更で、サーバー側の中間証明書不足・時刻・企業proxy・別のTLS backendでは別の対応が必要です。原因を調べ、承認されたCA/信頼ストアや接続先を直します。未知のCAを取り込まず、下の読取例から設定元を確認します。

# 証明書ストア更新
sudo apt install ca-certificates
sudo update-ca-certificates

# 暫定回避（推奨しない）
git config --global http.sslVerify false

FAQ

Q: snap や flatpak で入れていい？
A: 配布元/サポート・sandboxやファイルアクセス・SSH agent/IDEとの連携を確認します。「snapならhooksが動かない」という一律の非推奨理由は示しません。必要な操作を選んだ環境で検証してください。

Q: rpm / deb の手動ダウンロードで入れたい
A: Git公式のLinux導入ページと対象OSの配布手順から確認します。OS版/architecture・依存・署名/配布元・保守を確認し、別OS用のrpm/debや不明な追加repoを混ぜません。RHEL系なら追加repoが必要と一般化しません。

Q: WSL の Ubuntu で入れた git と Windows の Git Bash、どう使い分け？
A: WSL内のLinux GitとGit for Windowsのどちらが実行されるか確認します。同じ作業ツリーの共有では改行/属性・実行bit・大文字小文字・権限・PATH/認証設定や同時操作に注意が必要です。常に不可能とも、設定なしで同じとも扱いません。

関連

• git config — 初期設定
• SSH 鍵作成 — 認証セットアップ
• GitHub CLI (gh) — PAT 管理 + リポジトリ操作
• git-lfs — 大容量ファイル対応、別途インストール

版の比較表を読む前の確認

上の表は固定の古い数字を現行値として使わないため、確認方法へ訂正しています。OSのrelease/architecture、有効repo、インストール済み版と候補版、修正情報・保守範囲を照合します。apt-cache policy git、dnf info git、pacman -Qi git、apk policy git等も対象OSで選び、全コマンドを一括実行しません。表示版の新しさと、配布元が必要な修正を提供しているかは別です。

TLS設定を変更せずに確認する

次はBash/Git向けの読取例です。新しいファイルinspect-tls.shへ保存し、bash inspect-tls.sh https://git.example.invalid/repo.gitのように対象URLを引数で指定します。例示ドメインへの接続は行いません。実URLにトークン等を含めず、設定元のパス等を共有するときは内部情報を確認します。

set -eu

# Read configuration only: no connection, helper invocation, or setting changes.
command -v git
git --version
url=${1:-https://git.example.invalid/repo.git}

if git config --show-origin --show-scope --get-all http.sslVerify; then
    :
else
    status=$?
    if [ "$status" -ne 1 ]; then exit "$status"; fi
    printf '%s\n' 'No explicit generic http.sslVerify value.'
fi

if git config --type=bool --get-urlmatch http.sslVerify "$url"; then
    :
else
    status=$?
    if [ "$status" -ne 1 ]; then exit "$status"; fi
    printf '%s\n' 'No matching http.sslVerify value; Git default is true.'
fi

if [ "${GIT_SSL_NO_VERIFY+x}" = x ]; then
    printf '%s\n' 'GIT_SSL_NO_VERIFY is set; inspect it privately. Its value is not printed.'
fi

最初の出力は汎用キーの全設定元、次は指定URLに一致する設定値です。URL別のfalseを汎用キーだけの確認で見落とさないでください。未設定による終了1と構文エラー等を分け、Git既定値はtrueでもGIT_SSL_NO_VERIFY等の環境指定を別途調べます。環境変数の値はこの例では出力しません。CAInfo/CAPath・TLS backend・proxy等も関係するので、これだけで全通信条件の安全性を保証しません。

既存のfalseを見つけても、未確認のglobal削除や別scopeへのtrue追加で隠しません。設定元・URL別指定・環境変数と管理者の意図を確認し、正しい信頼経路を用意して元の無効化を解消します。承認されたCAファイルの指定も実際のTLS backend/配布元で確認します。社内proxyの秘密値や資格情報ファイルを画面へ貼り付けないでください。

導入できた後の確認順

1. 今のシェルとIDE/サービスで使われるGitの実体、版、配布元の更新状態を確認する。
2. commitを作る対象リポジトリに作者名/公開してよいメールを設定し、秘密値や不要ファイルを含めずローカルでcommitする。
3. 接続先ごとのHTTPS/SSH認証、TLS/ホスト鍵、権限を確認。認証だけでpushや履歴の安全を保証しない。
4. 更新時の影響と復旧を用意する。全OS更新・配布元追加・ソースinstall・global設定を単なる確認の続きで実行しない。

新規のローカルbareへpush/cloneする練習はLinuxサーバーとクライアントのセットアップ、設定値はGitの設定確認、SSHはSSHの説明を参照。Gitの親ページの子ページから選択してください。

公式資料と検証範囲

2026年10月にGitのLinux導入、Ubuntuのbackport/保守範囲、Archの部分更新非対応、pacmanの更新操作、IUSの保守終了、CentOSのサポートと照合しました。

認証/通信はGit設定/TLS、storeの平文保存、cacheの一時保存、GitHubの認証連携、PATの権限、SSH接続確認を確認しています。追加読取例は隔離した設定で実行し、TLSの不信任/CA信頼/名前不一致をローカルHTTPSだけで検査しています。各Linuxの実インストール・更新/ソースbuild、実GitHub認証や企業proxy・各TLS backend全体を検証したものではありません。