Gitの小ネタおれおれAdvent Calendar 2022 – 22 日目
remote といえば origin というくらいこれひとつしか使わないんですが、違うものを追加したい場面もあります。昔は Heroku へコードを送るのがそういうやり方だったと思います。
あと GitHub で OSS をフォークして更新して貢献するときとか。Pull Request 作成の前に本流の更新を一通り自分のブランチに入れておきたいですよね。コンフリクトも先に修正できるし。
上流のブランチを手元へマージする手順
先にまとめ。
git remote addで上流リポジトリーの情報を手元の Git へ登録git fetchで上流リポジトリーの最新のコミットを取得git mergeで手元のブランチへ取り込む
git remote
リモート（サーバーにあるリポジトリー）の管理を行うサブコマンドです。
あんまり使わないんじゃないかと思います。だいたいプロジェクトの最初の最初に誰かが git remote add … とかして、その後は git clone するだけですよね。
サーバーのリポジトリーという概念をどう説明するのが良いかはちょっとわかんないんですが、git push とかでやり取りする宛先です。なんだろ API のエンドポイントみたいな？ 同じ宛先に push やら pull やらのアクションを実行する感じです。Git 的には “remote” という呼び方みたい。
というわけでフォーク元の remote を追加します。git remote add <名前> <URL> です。
フォーク元の上流は名前を upstream とするのが伝統みたいです、知らんけど。
登録する URL は GitHub のリポジトリーページとかで見つけてきてください。例として [email protected]:ginpei/example-original.git であるということにします。
$ git remote add upstream [email protected]:ginpei/example-original.git
git remote でエラーが出なければ結果を確認します。-v, --verbose オプションを付けないと名前しか出てこないです。
$ git remote -v
origin [email protected]:ginpei/example-forked.git (fetch)
origin [email protected]:ginpei/example-forked.git (push)
upstream [email protected]:ginpei/example-original.git (fetch)
upstream [email protected]:ginpei/example-original.git (push)
git fetch
まだ URL を登録しただけです。続いてその URL から最新の状態を手元へダウンロードしてきます。
リモート名 upstream と目的のブランチ名 main を指定します。ブランチ名の方は省略すると全部取ってきます。
$ git fetch upstream main
git merge
ようやくマージです。作業中の自分のブランチへ移動して、<リモート名>/<ブランチ名> を指定して git merge です。
$ git switch myWorkingBranch
$ git merge upstream/main
なおマージ時にリモート名を省略するとたぶんエラーになる↓か、pull とかしてなければ古い状態のままなので欲しいものはマージされません。
$ git merge main
merge: main - not something we can merge
Did you mean this?
upstream/main
コンフリクトしたら
$ git merge upstream/main
Auto-merging some-file.md
CONFLICT (content): Merge conflict in some-file.md
Automatic merge failed; fix conflicts and then commit the result.
コンフリクトしたらよしなに修正して、<<<<<<< HEAD とかそういう行もなくなったら git merge --continue してください。がんばれ～。
$ git add .
$ git merge --continue
不要なリモートを削除
なんか間違えたりとかしたら add の並びに remove というのがあります。削除するときは URL いらないです。
$ git remote remove upstream
必要に応じて rename というのもあります。
おしまい
GitHub のおかげでフォークするのは気軽なんだけどそれを元のリポジトリーへ反映させようと思うとちょっと手間ですね。