【GitHub】リモートリポジトリとpush・pull・clone・fetchの使い方を解説

Git

こんにちは、かつコーチです。

SSH鍵の設定が終わり、GitHubに接続できるようになったら、いよいよ実際にファイルをやり取りしていきましょう。

pushpullclonefetchは、どれも似たような名前で混同しやすいコマンドです。

この記事では、それぞれの違いを「荷物のやり取り」に例えながら整理します。

読み終える頃には、どの場面でどのコマンドを使えばいいか、迷わず判断できるようになります。

リモートリポジトリとは?

リモートリポジトリ=GitHub上に置いた「共有の荷物置き場」

リモートリポジトリとは、GitHub上に置かれているリポジトリのことです。

これに対して、自分のパソコンの中にあるリポジトリをローカルリポジトリと呼びます。

たとえるなら、ローカルリポジトリは「自分の部屋にある荷物」、リモートリポジトリは「みんなで使う共有の荷物置き場」だとイメージしてください。

自分の部屋で作業した内容(コミット)を、共有の荷物置き場に送ったり、逆に置き場から荷物を受け取ったりする、その一連の「荷物のやり取り」がpushpullにあたります。

なぜリモートリポジトリが必要なのか

自分の部屋(ローカル)だけで作業していると、パソコンが壊れたときにすべての記録が失われてしまうリスクがあります。

また、チームメンバーが自分の部屋の中を直接見ることもできません。

共有の荷物置き場であるリモートリポジトリを介することで、バックアップとしての役割を果たしつつ、チーム全員が同じ荷物(最新のコード)にアクセスできるようになるのです。

基本の使い方:clone・push・pull・fetch

手順1:clone=荷物置き場を丸ごとコピーしてくる

cloneとは、リモートリポジトリの中身を、履歴ごとまるごと自分のパソコンにコピーしてくる操作です。

git clone git@github.com:your-username/sample-repo.git
cd sample-repo

これは、荷物置き場に置いてある段ボールを、中身も含めてそのまま自分の部屋に持ってくるようなイメージです。

一度cloneすれば、以降はそのフォルダの中でGitのコマンドが使えるようになります。

手順2:push=自分の変更を荷物置き場に送る

自分の部屋(ローカル)でコミットした変更を、共有の荷物置き場(リモート)に送るのがpushです。

# ファイルを編集した後
git add .
git commit -m "READMEにセットアップ手順を追記"
git push origin main

originはリモートリポジトリの標準的な呼び名、mainは送り先のブランチ名です。

荷物置き場の宛先(origin)を指定して、荷物(コミット)を送り届けているとイメージすると覚えやすいです。

手順3:pull=荷物置き場から最新版を受け取る

他のメンバーがリモートに送った変更を、自分のパソコンに反映するのがpullです。

git pull origin main

これは、荷物置き場に新しく届いた荷物を、自分の部屋に運び込んでくる操作にあたります。

手順4:fetch=荷物置き場の様子だけ確認する

fetchは、リモートの最新情報を取得はするものの、自分の作業中のファイルには反映しない操作です。

git fetch origin
git log origin/main --oneline

これは、荷物置き場まで見に行って「どんな荷物が届いているか」だけ確認し、まだ自分の部屋には運び込まない状態です。

pullは「fetch+自分の作業に取り込む」処理をまとめて行っている、と理解すると整理しやすくなります。

つまずきやすい設定・注意点

pushする前に、リモート側で他の人の変更が進んでいると、送り先の状態が自分の手元と食い違ってしまうことがあります。

そのためpushする前に一度git pullしておくと、余計なコンフリクトを避けやすくなります。

よくあるつまずきポイント・エラー対処

「pushしたのに反映されない」で悩んだ話

実際に私がチーム開発の練習中につまずいたのが、このエラーでした。

❌ Before

git push origin mainを実行したところ、以下のようなエラーが表示され、荷物が送れませんでした。

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:your-username/sample-repo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

最初は「なぜ拒否されるのか」がわからず、--forceオプションで強引に上書きしようとしてしまいました。

これは、荷物置き場に他の人が置いた荷物を無視して、自分の荷物で上書きしてしまうような危険な行為です。

✅ After

落ち着いて、まずはgit pullでリモートの最新状態を自分の手元に取り込むことにしました。

git pull origin main

コンフリクトがあれば解消し、改めてコミットしてからpushし直したところ、無事に反映されました。

git add .
git commit -m "コンフリクトを解消"
git push origin main

この経験から、「rejected」と表示されたら、まずpullで状況を確認するのが基本だと学びました。

--forceは自分以外の変更を消してしまう可能性があるため、チーム開発では特に慎重に扱うべきだと実感しています。

応用・一歩先の使い方

upstreamの設定でコマンドを簡略化する

毎回git push origin mainと書くのが面倒な場合は、追跡ブランチ(upstream)を設定しておくと、git pushだけで済むようになります。

git push -u origin main

一度-u--set-upstream)を付けてpushしておけば、次回以降はブランチ名を省略できます。

git push
git pull

これは、荷物の送り先をあらかじめ登録しておくことで、毎回宛先を書かなくても発送できるようにする設定だとイメージしてください。

まとめ

この記事のポイント

  • リモートリポジトリとは、GitHub上にある「共有の荷物置き場」のこと
  • cloneは荷物置き場を丸ごとコピー、pushは変更を送る、pullは最新版を受け取る操作
  • fetchはリモートの状態確認だけ行い、作業中のファイルには反映しない
  • pushrejectedになったら、まずpullで状況を確認するのが基本

次に読むべき記事

リモートでのやり取りに慣れたら、次はチームでのタスク管理に使う「Issue」の使い方を見ていきましょう。

「Issueの使い方:課題やタスクを見える化する」で、付箋のように課題を管理する方法を解説しています。

タグ: #GitHub #初心者向け #環境構築

タイトルとURLをコピーしました