Git導入と初回push｜Linuxサーバー・Windows/macOS・SSH設定

Linuxサーバーのbareリポジトリと、Windows/Linux/macOSクライアントを準備する記事です。Gitの導入、作者情報、SSH接続、commit/pushを分けて確認します。

既存の黒いコード表は元手順として保持しています。OSや名前・パスに依存する箇所は直前の訂正を読み、最初は本番ではなく新しい練習用ディレクトリで確認してください。

本稿はサーバー(Linux)およびクライアントにgitを導入する手順を記載する。

前提条件

元記事のサーバーOSはCentOSです。ただしCentOS Linux 7は2024年6月30日にサポート終了済みで、新規導入先として案内しません。CentOS Streamは別のライフサイクルです。現在サポート中のOSと、その配布元が保守するGitパッケージを選んでください。

クライアントOS:Windows / Linux / Mac のいずれか

サーバーにgitのセットアップ

■gitのインストール

　※レンタルサーバー等の場合は既に導入されている場合もあるので「git --version」で存在するかチェックしましょう。

Red Hat系の旧例です。現在の対象OSでは配布元の手順に従い、dnf等の利用可否・リポジトリ・権限を確認します。yumコマンドが存在することとOSがサポート中であることは別です。

Debian系

■ユーザーとemailの登録

これは作者情報であり、SSHのログイン名や認証設定ではありません。commitを作るクライアントに自分の名前と公開してよいメールを設定します。--globalは同じOSユーザーの他リポジトリにも効くため、使い分ける場合は対象リポジトリで--localを選びます。受け取り専用のbareサーバーに作者情報を設定することはpushの前提ではありません。下のguser/~@~.comは例で、そのまま使用しません。

■リポジトリの作成

次は新規の保存先を作る旧例です。実際の絶対パスと利用ユーザーを先に決めます。--sharedはファイル/ディレクトリの共有権限に関する指定で、SSH認証や利用者ごとのリポジトリ認可は作りません。所有者・グループ・親ディレクトリの通過権限も別途必要です。安易なchmod 777や全員共通の秘密鍵で解決しないでください。

bareはチェックアウトした作業ツリーを持たないリポジトリです。コミットやファイル内容はGitのオブジェクトとして保存されます。「管理情報しか保存しない」という意味ではありません。サーバー上にWeb公開用のファイルを配置する操作とも別です。

クライアントにgitのセットアップ

Windowsの場合はこちらからWindows向けのgitをダウンロードする。

Windowsは公式のGit for Windowsを利用し、既存Git・PATH・SSHクライアント・改行設定との関係を確認します。全員が無条件で同じ設定にする必要はありません。導入後は使うターミナルでgit --versionを確認してください。

デスクトップ上で右クリックすると、「Git Bash」を開けるようになるので開く。

次のaptはDebian/Ubuntu系Linux用です。macOSの標準ターミナルにaptを入力する手順ではありません。macOSはGit公式の導入案内を確認し、Xcode Command Line Tools等の提供元と対応OSを選びます。git --versionを実行すると開発ツールの導入案内が出る環境もあります。

■ユーザーとemailの登録

これは作者情報であり、SSHのログイン名や認証設定ではありません。commitを作るクライアントに自分の名前と公開してよいメールを設定します。--globalは同じOSユーザーの他リポジトリにも効くため、使い分ける場合は対象リポジトリで--localを選びます。受け取り専用のbareサーバーに作者情報を設定することはpushの前提ではありません。下のguser/~@~.comは例で、そのまま使用しません。

■適当なプロジェクトを作成

■ローカルリポジトリの作成

通常のgit initでは作業フォルダに.gitディレクトリができます。linked worktree等では.gitが参照用ファイルの場合もあります。ls -aで存在を見るだけでなく、対象フォルダでgit statusとgit rev-parse --show-toplevelを確認し、別の親リポジトリで作業していないか確かめます。

■gitのインデックスに登録

現在位置以下の変更を広くステージするのが次のgit add .です。練習でも.env・秘密鍵・認証情報を入れず、git statusとgit diff --cachedで対象を確認します。追加例ではREADME.mdだけを明示的に選択しています。

■コミット

■sshconfigの設定

ここではSSHで自分のLinuxサーバーへpushする場合を説明します。HTTPSを使うリモートではSSH設定は不要で、ホスティング先が指定する認証方法を使います。

通常は実際に使うSSHクライアントのユーザー別の~/.ssh/configへ対象Hostの設定を追加します。下の旧説明にあるGit配布先のetc/ssh/ssh_configは全体設定なので、個人の接続先を設定するために上書きしません。Windows標準OpenSSHとGit同梱SSHでは実行ファイルやホームの解釈が異なる場合があり、Gitのcore.sshCommandや環境変数による指定も確認します。

下の旧設定は説明用の未完成例です。括弧付きの説明をPortの値等に貼り付けないでください。Hostの別名とremote URLを一致させ、HostName・User・秘密鍵の実パスは管理者から確認した値に置き換えます。実際の設定形式は下の追加例を参照してください。

SSHが分からない場合はこちらを参照。

■リモートリポジトリへの接続設定

次の/home/gitpro.gitは絶対パスの例です。先ほどのmkdirをホームディレクトリ内で実行しただけなら、このパスと一致するとは限りません。管理者が作成したbareの実パスと、SSHユーザーの読書き権限を確認してからURLに指定します。

remote addはoriginという名前とURLをローカルのリポジトリ設定へ登録します。サーバー上のリポジトリ作成・SSH鍵登録・権限付与は行いません。originが既にあると失敗するため、先にgit remote -vで確認し、既存設定を削除してやり直すことを初手にしないでください。

.gitは通常は隠しディレクトリです。設定の確認にはgit config --local --get remote.origin.url等も使えます。URLに秘密値を埋め込まず、設定や診断ログを共有する場合は秘密情報を確認してください。

■リモートリポジトリへのプッシュ

下のmasterは旧例のブランチ名です。現在のブランチ名をgit branch --show-currentで確認し、mainならmainを指定します。最初のcommit前は送信するブランチの参照がまだなく、名前だけ直してもpushできません。既存ブランチを強制改名したり、拒否されたpushへ--forceを追加したりしないでください。

push後は意図したブランチのコミットが届いたことを確認し、別の作業場所へのcloneで履歴とファイルを照合します。push成功だけで、公開配置・バックアップ・復元・アクセス制御まで完了したとは扱いません。

SSHの設定例と接続前の確認

次のHost名・ホスト名・鍵名は練習用です。git.example.invalidは実接続先ではありません。既存の~/.ssh/configを丸ごと置き換えず、既存Hostとの一致順を確認して必要な部分だけ追加します。一般的な設定は先に得た値が優先されますが、IdentityFileは複数指定が追加される点にも注意します。

Host git-training
    HostName git.example.invalid
    Port 22
    User git
    IdentityFile ~/.ssh/id_git_example
    IdentitiesOnly yes

この例を新しいファイルgit-training.confへ保存し、ssh -G -F git-training.conf git-trainingでhostname/user/port/identityfile/identitiesonlyを確認できます。-Gは設定を評価して終了するため、SSH認証やネットワーク接続の成功確認ではありません。未知の設定にはMatch exec等が含まれることがあるので、入手元不明の設定をこの方法で安全に検査できるとは考えないでください。

実接続前には既存鍵を確認し、新しい鍵を作る場合も既存ファイルを上書きしません。秘密鍵は手元で保護し、登録するのは公開鍵です。サーバー側の管理者にアカウント・許可鍵・リポジトリのパス/権限を確認します。初回接続のホスト鍵指紋は信頼できる別経路で照合し、検証を無効化して接続しないでください。認証成功と、対象リポジトリの読書き許可は別です。

ネットワークなしで初回pushとcloneを練習する

Git 2.28以降とBash向けです。WindowsではGit Bashで実行し、PowerShellへそのまま貼り付けません。まず新しい空の練習用フォルダへ移動してください。remote.git/work/checkoutがある場合は何も変更せず停止します。サーバーの代わりに同じPC内の新規bareを使うので、SSH接続・Linux側の権限を検証する例ではありません。

set -eu

# Run only in a new, empty practice directory, using Bash and Git 2.28+.
if [ -e remote.git ] || [ -L remote.git ] || [ -e work ] || [ -L work ] || [ -e checkout ] || [ -L checkout ]; then
    printf '%s\n' 'Practice paths already exist; stop without changing them.' >&2
    exit 1
fi

git init --bare --initial-branch=main remote.git
git init --initial-branch=main work
git -C work config --local user.name "Example Author"
git -C work config --local user.email "author@example.invalid"
printf '# Git practice\n' > work/README.md
git -C work add -- README.md
git -C work diff --cached --check
git -C work diff --cached
git -C work commit -m "Add practice README"
git -C work branch --show-current
git -C work remote add origin ../remote.git
git -C work remote -v
git -C work push -u origin main

# A bare repository stores committed file contents, without a working tree.
git --git-dir=remote.git show main:README.md
git clone remote.git checkout
git -C checkout log -1 --oneline
git -C checkout status --short

途中で失敗したらエラーを確認し、同じフォルダに繰り返し上書きしません。成功時はbareのshowがREADMEの内容を表示し、clone先のstatus --shortには変更が出ません。workのmain、bareのmain、checkoutのHEADのコミットIDは一致します。作者情報はworkのローカル設定に限定し、普段の--global設定を変更しません。mainはこの新規練習で明示した名前で、既存プロジェクトの改名指示ではありません。

失敗した場所から切り分ける

続きはclone、設定値の確認、pushへ。Gitの親ページの子ページから選択してください。

公式資料と検証範囲

2026年10月にGitのOS別導入、CentOSのライフサイクル、init/bare/shared、作者情報と設定範囲、remote、push、OpenSSH設定、sshの-Gと照合しました。追加例は隔離した新規リポジトリでcommit/push/cloneとbare内の内容を確認し、SSH例は接続なしで設定を評価しています。各OSのインストーラー、実SSH認証・サーバー権限、バックアップ復元や本番公開配置の動作を検証したものではありません。