Gitリモートリポジトリの作成｜初回push・既存履歴・mirrorの注意

Gitのリモートは作成後にURLを登録し、空か既存履歴があるかを確認して接続します。通常の初回push、別履歴の統合、mirror、バックアップを混同しないことが重要です。

元コード8ブロックを保持し、履歴結合/削除/上書きや公開設定の注意を直前に追加しています。

リモートリポジトリとは

remoteは別のリポジトリをURLと名前で参照する仕組みで、同じPC上のパスも使えます。ローカルrepoもアクセス方法と権限があれば共有可能です。ホスティング先は共同作業やCI連携に使えますが、pushしただけで設定/世代保持/復元を含むバックアップが完成するわけではありません。

代表的なホスティング:

GitHub での作成手順

1. 右上の + → New repository
2. Repository name: myapp
3. Description: 説明（任意）
4. Public / Private: 公開範囲
5. Add a README file: 初期化するとリモートに履歴ができる。既存ローカルrepoを送る場合はREADME等で初期化しない作り方を選ぶ
6. Add .gitignore: 必要なテンプレートを確認。既存repoのファイルや追跡状況を置き換える操作とは別
7. Choose a license: 権利者・既存ライセンス/配布方針に基づき選ぶ。空repoへ既存履歴を送る場合の初期化にも注意する
8. Create repository

作成後、URL を取得します:

次のURLは接続先の形式例で、実際の所有者/repoに置き換えます。SSHを常に推奨、HTTPSをCI専用と分類しません。組織の認証/端末/通信制約に合わせ、SSH鍵/ホスト鍵やHTTPSのTLS/認証を別途準備します。

# SSH (推奨)
git@github.com:user/myapp.git

# HTTPS (CI 等)
https://github.com/user/myapp.git

ローカルからリモートへの紐付け

次のA/B/Cは選択肢で、一括実行しません。Aは送るcommit/branchと空の送り先を確認し、既存originを先に確認します。git branch -M mainは強制改名なので統一のためだけに実行しません。Bは既存README等の履歴をcloneから受け取る方式です。Cの--allow-unrelated-historiesは独立した履歴の結合を許可する例外で、通常の接続エラーの解決策ではありません。pull方針やconflict・両履歴の意味/退避を調べ、force pushや無条件の結合で上書きしません。

# ケース A: ローカル既存 → 空リモートに push
cd ~/projects/myapp
git remote add origin git@github.com:user/myapp.git
git branch -M main           # ブランチ名 main に統一
git push -u origin main

# ケース B: README 等を入れて作った GitHub リポジトリを clone
git clone git@github.com:user/myapp.git
cd myapp

# ケース C: ローカルとリモートに別履歴があり一発で繋ぎたい
git remote add origin git@github.com:user/myapp.git
git pull origin main --allow-unrelated-histories
# コンフリクト解決 → commit → push
git push -u origin main

自前サーバに bare リポジトリで構築

bareは作業ツリーを持たない履歴の保存先です。SSH認証、リポジトリ単位の認可、OS/サービス保守・監査/鍵の失効・容量/バックアップ/復元は別途必要です。initだけで安全なサーバー運用が完成する、費用ゼロや全社に最適、と断定しません。

次はサーバーを変更する旧例で、useradd/su/initや鍵追記を診断として実行しません。既存ユーザー/パス・所有者/グループ・親パスの権限とGitの実体を確認します。共通gitユーザーと通常shellを与えただけではrepo別認可はできません。鍵の失効・制限されたコマンド/操作と復旧を設計してください。

# サーバ側 (例: git ユーザーで運用)
sudo useradd -m -s /bin/bash git
sudo su - git

mkdir -p /home/git/repos/myapp.git
cd /home/git/repos/myapp.git
git init --bare
# Initialized empty Git repository in /home/git/repos/myapp.git/

# 公開鍵を /home/git/.ssh/authorized_keys に追加
# （複数開発者で共有）

# クライアント側
git remote add origin git@server.example.com:/home/git/repos/myapp.git
git push -u origin main

HTTP / smart-http で公開

次は公開設定の断片で、完成した安全設定ではありません。CGI/module・backendパス・実行ユーザーとfilesystem権限、TLS終端、読取/書込の認証とrepo別認可を確認します。GIT_HTTP_EXPORT_ALLは公開可否の印を確認せずexportする指定で、全repoの公開を安易に許可しません。Require valid-userだけでは利用者ごとのrepo権限を分離できず、認証済みreceive-packの扱いも対象構成で確認します。Basic認証を保護されない通信へ載せたり、既存Web設定へ丸ごと追記したりしません。

# Apache + git-http-backend で HTTP push/pull 可能
# /etc/apache2/conf-available/git.conf
SetEnv GIT_PROJECT_ROOT /var/git/repos
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

<Location /git>
  AuthType Basic
  AuthName "Git"
  AuthUserFile /etc/apache2/git.passwd
  Require valid-user
</Location>

# クライアント
git clone https://server.example.com/git/myapp.git

README / LICENSE / .gitignore

次のcat/curlのリダイレクトは既存ファイルを上書きします。README/LICENSE/.gitignoreを一括置換しません。取得失敗やHTML応答をLICENSE等へ書き込む可能性、取得元と内容・既存ルール/権利者を確認します。MITテンプレートは確認時点でyear/organizationの未置換値を含み、そのまま完成ライセンスではありません。Laravelテンプレートもプロジェクトに合わせて差分レビューし、既に追跡した秘密値は.gitignore追加だけでは消えません。README内のkey:generate等はこのGit作業のために既存アプリへ実行する指示ではありません。

# 既存リポジトリにあとから足す場合
cat > README.md <<'EOF'
# myapp

## Setup
1. composer install
2. cp .env.example .env
3. php artisan key:generate

## Test
- php artisan test
EOF

# MIT ライセンス
curl https://raw.githubusercontent.com/licenses/license-templates/master/templates/mit.txt > LICENSE

# .gitignore (言語別テンプレートから)
curl https://raw.githubusercontent.com/github/gitignore/main/Laravel.gitignore > .gitignore

git add README.md LICENSE .gitignore
git commit -m "Add README, LICENSE, .gitignore"
git push

Organization での運用

次の構成は例で、開発者全員へ全repoのWriteやinfraのAdminを一律付与する推奨ではありません。最小権限/担当範囲・外部協力者/失効を確認します。CODEOWNERSのレビュー要求は有効な対象/権限とbranch保護等も必要で、ファイルを置くだけで承認を必須にできるわけではありません。

GitHub Org の典型構成:

myorg/                           Organization
├── frontend                     リポジトリ
├── backend
├── docs
└── infra

メンバー権限:
- Owner       : Org 全体管理
- Member      : 通常メンバー
- Outside      : 外部協力者（特定リポジトリのみ）

Team:
- @myorg/dev        : 開発者全員（Write 権限を全リポジトリに）
- @myorg/ops        : 運用（infra リポジトリ Admin）
- @myorg/reviewers  : レビューワー（プルリク CODEOWNERS で自動アサイン）

SSH / HTTPS の切り替え

次の変更/削除/renameを確認コマンドとして一括実行しません。URLに資格情報を入れず、remote -vの出力を共有する前も点検します。fetch/pushを同じrepoの別通信方式にすることと、別repo間の同期は区別します。明示したpush URLはfetch URLの変更だけでは変わらない場合があり、両方を確認します。remote removeはローカルのremote設定等を外すもので、サーバーのrepo削除ではありません。

# 現状確認
git remote -v
# origin  https://github.com/user/myapp.git (fetch)
# origin  https://github.com/user/myapp.git (push)

# HTTPS → SSH に変更
git remote set-url origin git@github.com:user/myapp.git

# SSH → HTTPS に変更
git remote set-url origin https://github.com/user/myapp.git

# fetch と push で別 URL（push は SSH に強制）
git remote set-url --push origin git@github.com:user/myapp.git

# リモート追加・削除
git remote add upstream git@github.com:original/myapp.git
git remote remove upstream
git remote rename origin github

ミラーリポジトリ

mirror pushは移送/同期用の専用操作で、通常のbranchのpushや世代保持バックアップとは分けます。送り先だけの参照を消し、非fast-forwardの強制更新も行い得るため、共同編集する送り先へそのまま適用しません。LFS実体・submoduleの別repo、Issues/PR・権限/保護設定等まで自動複製するものでもありません。

次のmirrorは参照の削除・強制更新を含む専用移送例です。通常の作業repoへ適用しません。mirror cloneのfetchはrefを上書きし、remoteのmirror設定によって通常のpushもmirrorとして動く場合があります。送り先だけのbranch/tag等を守るバックアップではありません。旧cron例のgitlab remoteは前の行で追加されておらず、そのままの定期実行は不完全です。自動化には方向/対象/権限・保護設定、世代/復元、同時実行/失敗通知と監査を別途設計し、cronをこの例から登録しません。

# ベアでクローン
git clone --mirror git@github.com:user/myapp.git
cd myapp.git

# 別リモートを追加
git remote set-url --push origin git@gitlab.com:user/myapp.git

# 全ブランチ・タグ・参照を push
git push --mirror

# 定期同期 (cron で)
*/15 * * * * cd /srv/mirror/myapp.git && git fetch -p origin && git push --mirror gitlab

Private / Public の判断

FAQ

Q: 間違って .env を push してしまった
A: 漏えい範囲を調査し、まず秘密値の失効/ローテーションと利用先への影響を管理します。Privateでもアクセスできるコピー等への露出は残ります。履歴の書換えは別途、関係者/全ref・コピー・退避/復旧を含めて判断し、filterやforce pushだけで他者のclone/キャッシュから消えたと保証しません。

Q: 既に main と master の 2 ブランチがある
A: どちらの履歴に何があるか、default/protected branch・PR/CI/利用者の参照先を調べます。main/masterの併存は自動的に異常ではありません。旧例のgit push origin :masterはリモートbranchの削除なので、名前が2つあるという理由だけで実行しません。統一は合意/退避/移行確認のある別作業です。

Q: 自前 Git サーバの認証は SSH 鍵で全部済ませたい
A: SSHの認証とrepo別の読書き許可・shell権限を分けます。共通OSユーザーのauthorized_keysへ鍵を追加するだけでは、開発者ごとのrepo権限や追跡/失効の設計は完成しません。制限された実行経路やGitolite/Gitea等の仕組みも対象構成で確認し、秘密鍵は共有しません。

README付きリモートはcloneから始める

Bash/Git 2.28以降で、新しい空の練習用フォルダから実行します。3つの練習先が既存なら停止します。サーバー側のREADME作成を同じPC内で模擬し、その履歴をcloneした上に変更を加えます。既存repoのファイル/branchを改名・削除せず、global作者設定や実サービスを変更しません。

set -eu

# Bash / Git 2.28+: use only a new, empty practice directory.
for name in server-seed readme-remote.git work; do
    if [ -e "$name" ] || [ -L "$name" ]; then
        printf '%s\n' 'Practice path already exists; stop without changing it.' >&2
        exit 1
    fi
done

# Simulate a server that already has a README commit.
git init --initial-branch=main server-seed
git -C server-seed config --local user.name "Example Author"
git -C server-seed config --local user.email "author@example.invalid"
printf '# Existing project\n' > server-seed/README.md
git -C server-seed add -- README.md
git -C server-seed commit -m "Create initial README"
git clone --bare server-seed readme-remote.git

# Start from that history instead of initializing an unrelated repository.
git clone readme-remote.git work
git -C work config --local user.name "Example Author"
git -C work config --local user.email "author@example.invalid"
printf 'Practice change\n' > work/example.txt
git -C work add -- example.txt
git -C work diff --cached --check
git -C work commit -m "Add example file"
git -C work push -u origin main
git -C work log --oneline
git -C work rev-parse HEAD
git --git-dir=readme-remote.git rev-parse main

最後の2つのcommit IDが一致し、元READMEのcommitが履歴に残れば確認できています。既に独立して作ったローカル側にも変更がある場合は、この例で消したり上書きしたりせず、別途両方の履歴/差分を保持して方針を決めます。空リモートへの練習はサーバーとクライアントのセットアップも参照してください。

mirrorは専用の送り先へdry-runで影響を調べる

次は専用bare mirror作業先でのみ使うBash例です。引数は自分が管理し確認した送り先のURLまたはパスで、資格情報を埋め込みません。通常作業repoなら停止しますが、bareであることだけで安全な対象と証明するものではありません。実行前に元/先の完全な参照・独自branch/tag・世代保存と復旧先を確認します。

set -eu

# Run only inside a dedicated, reviewed bare mirror clone.
if [ "$#" -ne 1 ]; then
    printf '%s\n' 'Usage: bash mirror-preview.sh DESTINATION' >&2
    exit 2
fi
if [ "$(git rev-parse --is-bare-repository)" != true ]; then
    printf '%s\n' 'Stop: a dedicated bare mirror is required.' >&2
    exit 1
fi

# Contacts the destination, but does not update its refs. Never remove --dry-run here.
git push --dry-run --mirror -- "$1"

--dry-runは送り先に接続しますが参照を実更新しません。削除/forced updateの予定を見て実行可否を検討するためのもので、成功しても後続実行時の認可/保護・hook・同時更新まで保証しません。この例から--dry-runを外して本番同期する手順にはしないでください。移送用mirrorと、書換え/削除前の状態を独立に保持するバックアップを分けます。

利用先と公開範囲の確認

サービス表は概要で、機能/料金・保守/リージョン/組織権限等の全条件を比較するものではありません。AWS CodeCommitは2024年の新規受付停止だけで終了と判断せず、AWS公式の2025年11月の新規受付再開案内を確認しています。IAM/VPC endpoint等は設計する選択肢で、利用すれば自動的に閉域になるという意味ではありません。今回、契約・課金・アカウント設定は行っていません。

Publicにする前には所有権/ライセンス・コード/履歴/添付物/CIログ/秘密値を確認します。Privateでも保存資格情報の管理や最小権限は必要です。README等の差分確認と、commit/push対象を確認し、全員共通の秘密鍵やトークンを配布しません。

導入はLinuxへのGit導入、作者設定は名前とメール、送信はpushへ。Gitの親ページの子ページから選択してください。

公式資料と検証範囲

2026年10月にpush/mirror/dry-run、clone/mirror、独立履歴の統合、remoteのURL/削除、HTTPの公開/認証、SSHサーバーの準備を確認しました。

GitHubへの既存コード追加、バックアップの範囲、CODEOWNERS、秘密値の失効/履歴変更、CodeCommitの受付履歴、AWSの再開案内とも照合。ライセンスは権利者/プロジェクトの判断事項で、この例で特定ライセンスの適用を決定しません。

追加例は新規の隔離repoで、README履歴の保持と初回push、独立履歴の通常merge拒否、mirror dry-runの削除/強制更新予定と送り先の無変更を検査しました。実GitHub等のUI/認証・課金、SSH/Apacheの公開設定、組織権限/保護ルール、LFSや運用復元を検証したものではありません。