GitHubリポジトリをクローンしてリモートを付け替え、自分専用にする手順

1. はじめに
2. リモートの役割としくみ
3. 手元の環境に複製する基本の手順
4. コミット履歴を持たずに複製する応用パターン
5. 手順の使い分け
6. 公開前に確認しておきたい権利関係
7. まとめ

はじめに

職業訓練校に通っている友人から、チーム開発で作ったソースコードをポートフォリオとして公開したいので、自分のリポジトリ(ソースコードや変更履歴を保存する場所)としてクローン(リポジトリの内容を丸ごと複製する操作)する方法を知りたいという相談を受けました。共有されたリポジトリをそのまま複製すると元のリポジトリとのつながりが残ってしまうため、独立したリポジトリとして扱うにはいくつか作業が必要です。今回は、リポジトリを複製して自分のものとして扱う方法について、備忘録としてまとめます。

リモートの役割としくみ

チーム開発で使っていたリポジトリを、自分だけの環境として複製したい場合、関係者への許可確認は必須ですが、それを踏まえたうえで元との関係を断ち切り、自分専用の独立したリポジトリとして管理できる形にする必要があります。

このときに理解しておきたいのが、リモート(ローカル環境から参照する外部リポジトリに付けられたニックネーム)の仕組みです。Gitでは慣習的に最初のリモートにoriginという名前が付けられますが、これは単なる呼び名であり、Gitの動作そのものに特別な意味を持つ予約語ではなく、名前を変えても、Git自体の動作には影響がありません。

リモートの設定は、リポジトリ内の.git/configというファイルにテキストとして保存されています。実際にクローン直後の.git/configを開くと、次のような内容が書き込まれています。

[remote "origin"]
    url = https://github.com/other-user/team-project.git
    fetch = +refs/heads/*:refs/remotes/origin/*

urlは参照先の外部リポジトリのURLを、fetchはoriginが持つすべてのブランチを手元でorigin/ブランチ名として参照できるようにする設定をそれぞれ表しています。

git remote -vで確認できる一覧も、このファイルの内容を読み取って表示しているだけです。

# 現在設定されているリモートの一覧を確認する
git remote -v

実行すると、次のように2行が表示されます。

origin  https://github.com/other-user/team-project.git (fetch)
origin  https://github.com/other-user/team-project.git (push)

1行目の(fetch)はリモートからデータを取得するときに使うURLを、2行目の(push)はリモートへデータを送信するときに使うURLをそれぞれ示しています。通常はどちらも同じURLになりますが、取得元と送信先を別々のリポジトリに設定することも技術的には可能です。

つまりgit remote remove originのようにリモートを削除する操作は、.git/configから[remote "origin"]の記述を消しているだけであり、相手が管理している元のリポジトリには一切影響しません。

リモート操作と元リポジトリへの影響

git remote removeやgit remote addといったコマンドは、いずれもローカルの設定変更にとどまります。読み取り専用のgit cloneやgit pullも同様に、相手のリポジトリへ書き込みが発生することはありません。

影響が生じるのは、書き込み権限を持った状態でgit pushを実行した場合に限られます。相談を受けたときも、この違いを最初に伝えました。

手元の環境に複製する基本の手順

最初に、共有されたリポジトリをそのまま手元にクローンします。
URLの確認・コピーはGitHub上の対象リポジトリページ、「Code」ボタンから行えます。

次のコマンドは、共有リポジトリのGitHubリポジトリURLを入力してから実行してください。
※ 例: git clone https://github.com/team-name/team-project.git

# 共有リポジトリの内容を手元に複製する（上記の例のように共有リポジトリのURLを記載）
git clone 

クローンが完了すると、リポジトリ名と同じ名前のフォルダが作成されます。以降の操作はこのフォルダ内で行うため、cdコマンドで移動するか、エクスプローラー等のGUIで該当フォルダを開いてからターミナルを起動してください。

クローン直後の状態では、リモートとしてoriginが自動的に元のリポジトリを指すように設定されています。このままgit pushを行うと元のリポジトリへの書き込みを試みてしまうため、独立したリポジトリとして扱うには、リモート設定を削除する必要があります。

git remote remove origin

git remote remove originは元のリポジトリを指すoriginの設定を削除するコマンドです。この操作は手元の.git/configの記述を書き換えるだけであり、相手のリポジトリには一切影響しません。

コミット履歴を持たずに複製する応用パターン

友人の場合のように、元のプロジェクトでのコミット履歴を残さず、まっさらな状態からポートフォリオとして公開したいこともあります。この場合は、Gitの管理情報そのものを作り直すのが良いでしょう。

# Gitの管理情報(コミット履歴やリモート設定)を丸ごと削除
rm -rf .git

# 現在のフォルダを新しいリポジトリとして初期化
git init

続いて、コミット対象となるファイルをステージに追加します。

なお、公開したくないファイルがある場合は、先に.gitignoreを作成・編集して除外対象を登録してから次のコマンドを実行してください。順序を逆にすると、除外したいファイルがステージに含まれたままになります。

# すべてのファイルをステージ(コミット対象)に追加
git add .

次のコマンドは、コミットメッセージを入力してから実行してください。
※ 例: git commit -m "initial commit"

# 最初のコミットを作成（上記の例のようにコミットメッセージを記載）
git commit -m 

git commitの主なオプション

メッセージの指定

• -m "メッセージ" … コミットメッセージをコマンド上で直接指定
• -m "1行目" -m "2行目" … -mを複数回指定すると、段落が分かれた複数行のメッセージになります。1行目に要約、2行目以降に詳細を書く場合に便利

直前のコミットの修正

• --amend … 直前のコミットをやり直します。メッセージの打ち間違いを修正したい場合などに使用
• --amend --no-edit … メッセージを変更せず、ファイルの内容だけを直前のコミットに追加します。「コミット後にファイルの追加漏れに気づいた」場合に便利

次のコマンドは、ご自身のGitHubリポジトリURLを入力してから実行してください。
※ 例: git remote add origin https://github.com/your-name/portfolio-project.git

# 新しいリポジトリをoriginとして登録（上記の例のようにご自身のURLを記載）
git remote add origin 

URLの確認・コピー方法は、「手元の環境に複製する基本の手順」のgit cloneで説明したものと同じです（GitHub上の対象リポジトリページ →「Code」ボタン）。

ファイルの中身はそのままに、誰がいつどんな変更を加えたかという記録がすべてリセットされます。チームメンバー個人の名前がコミット履歴に残らなくなる点は、ポートフォリオとして公開する際に扱いやすい一方、開発の過程を見せたい場合には不向きです。

コミットを取り消した直後であれば、reflog(リフログ: HEADやブランチが指してきた位置の変更履歴)という仕組みを使って元のコミットに戻れる場合があります。ただしreflogの記録自体も.gitフォルダの中に保存されているため、rm -rf .gitでフォルダごと削除してしまうと、reflogを含めて復元の手がかりが残りません。この点は、コミットの取り消しをやり直せる操作と混同しないよう注意が必要です。

履歴がすべて失われる点に注意

.gitフォルダを削除すると、それまでのコミット履歴はすべて失われ、あとから復元することはできません。開発の過程や試行錯誤の跡を見せたい場合は、基本の手順のほうが適しています。

手順の使い分け

【手順ごとの向き不向き】

状況	向いている手順
チーム開発の変更履歴もポートフォリオとして見せたい	基本の手順(クローン後にリモートを付け替える方法)
まっさらな状態から自分のプロジェクトとして始めたい	応用パターン(.gitを削除して初期化し直す方法)

公開前に確認しておきたい権利関係

関係者への許可確認は必須と軽く触れた通り、手順としては独立したリポジトリを作れても、そのまま公開してよいかどうかは別の問題です。チーム開発の成果物には、自分以外のメンバーが書いたコードや、所属先などの権利が関わっていることがあります。ポートフォリオとして公開する前には、元のリポジトリの管理者に利用範囲を確認し、合意を得ておくと良いでしょう。友人にも、技術的に複製できることと、公開してよいことは別の話だという点をあわせて伝えました。

なお、この手順で作成したリポジトリは、GitHub上でフォーク(元のリポジトリと関連付けを保ったまま複製する仕組み)の関係を持たない、完全に独立したリポジトリになります。元のリポジトリの更新が自動的に反映されることはなく、逆にこちら側の変更が元のリポジトリの管理者に通知されることもありません。フォークのように元プロジェクトへプルリクエストを送るような使い方はできないため、あくまで自分専用のプロジェクトとして育てていく前提の方法になります。

まとめ

共有されたリポジトリを独立したリポジトリとして複製する方法と、その際に押さえておきたいリモートの仕組みについて整理しました。用途に応じて基本の手順と応用パターンを使い分け、公開前には元のリポジトリの権利関係も確認しておくことが大切です。