Macで作業した続きを、次の日にWindowsでやりたい。
複数PCでGitHubを使っていると、こんな疑問が出てきます。
毎回
git cloneするのか？
git pullの前にgit fetchした方がいいのか？
feature branchで作業していた場合はどうするのか？
どちらのPCが最新版なのか、どう判断するのか？
結論から言うと、基本は次の整理で考えると分かりやすいです。
| 状況 | 主に使う操作 |
|---|---|
| そのPCで初めて作業する | git clone |
| すでにclone済みで最新化したい | git pull |
| まずGitHub側の更新状況を確認したい | git fetch |
| 現在のbranchを確認したい | git branch --show-current |
| ローカルの変更状態を確認したい | git status |
| 別PCへ作業を渡したい | commit → git push
|
Git公式でも、git fetch はリモートからbranchやtagなどの情報を取得してremote-tracking branchを更新する操作、git pull は取得した変更を現在のbranchへ統合する操作として説明されています。 Git
この記事では、
Macで作業 → GitHubへpush → Windowsで続きを開始
という具体例を1本通して整理します。
1. 毎回 git clone する必要はない
まずここです。
別PCで作業するたびに、
git clone ...
する必要はありません。
git clone を使うのは、基本的にそのPCにまだRepositoryがない最初の1回です。
例えばWindowsで初めて作業するなら、
git clone git@github.com:USER/REPOSITORY.git
としてローカルRepositoryを作ります。
一度clone済みなら、2回目以降はそのRepositoryを更新して使います。
イメージとしては、
初回
GitHub
↓
clone
↓
Windows
2回目以降
GitHub
↓
fetch / pull
↓
Windows
です。
2. Mac側で作業を終える前に確認する
今回はMacで作業していて、次にWindowsへ移るケースを考えます。
まず現在のbranchを確認します。
git branch --show-current
例えば、
feature/header
と表示されたとします。
次に、
git status
を確認します。
ここで見たいのは、
- 未commitの変更が残っていないか
- untracked fileが残っていないか
- 想定したbranchで作業しているか
です。
3. 必要な変更をcommitする
変更が残っていれば、内容を確認してcommitします。
git add .
git commit -m "Update header"
必要なら、commit前に、
git diff
や、
git diff --cached
で差分も確認します。
4. GitHubへ push する
別PCへ移る前に、そのbranchをGitHubへ送ります。
すでにupstreamが設定されていれば、
git push
で十分です。
初回pushなら、
git push -u origin feature/header
のようにします。
ここまで行って初めて、
Mac側で行った変更がGitHub側から見える
状態になります。
5. 必要ならPull Request / mergeまで済ませる
作業内容によっては、
feature/header
↓
Pull Request
↓
mainへmerge
までMac側で終わらせる場合もあります。
逆に、feature branchのままWindowsへ続きを渡す場合もあります。
ここで重要なのは、
Windowsへ移る前に、Macだけに存在する未push変更を残さない
ことです。
6. Windows側で最初にやるのは git status
Windowsで作業を再開します。
対象Repositoryへ移動します。
cd D:\dev\project
いきなり git pull する前に、
git status
を確認します。
理由は、Windows側に以前の作業途中の変更が残っている可能性があるからです。
例えば、
modified: src/app.ts
が残っていた場合、何の変更か確認せずpullすると、後で分かりにくくなることがあります。
複数PC運用では、
まずローカル状態を見る
を固定しておく方が安全です。
7. 現在のbranchを確認する
続いて、
git branch --show-current
です。
例えばWindows側が、
main
にいるのか、
feature/header
にいるのかで、次の操作が変わります。
8. git fetch でGitHub側の最新情報を取得する
次に、
git fetch origin
を実行します。
git fetch は、GitHub側の最新情報を取得して、
origin/main
origin/feature/header
などのremote-tracking branchを更新します。
ただし、現在自分が開いているbranchや作業ファイルは、この時点では直接変更されません。 Git
つまり、
git fetch
=
GitHub側の状態をこちらへ教えてもらう
くらいの理解でよいです。
9. fetch後に何が変わったか確認する
まずbranch一覧を見るなら、
git branch -a
です。
例えば、
* main
remotes/origin/main
remotes/origin/feature/header
と表示されれば、GitHub側に feature/header が存在することが分かります。
mainの更新状況を確認したいなら、
git log --oneline HEAD..origin/main
なども使えます。
つまりfetchは、
いきなり現在のbranchへ取り込まず、まず状況を確認したい
ときに便利です。
10. git pull で現在のbranchへ反映する
現在のbranchを最新化したいなら、
git pull
です。
Gitでは、pull は基本的にリモートから変更を取得し、その内容を現在のbranchへ統合します。Git公式のユーザーマニュアルでも、git pull はfetchと統合処理をまとめて行う操作として説明されています。 Git
例えばWindows側でmainにいるなら、
git switch main
git pull
でローカルmainを最新にできます。
11. fetchとpullはどう使い分ける？
初心者向けには、次のように整理すると分かりやすいです。
fetch
git fetch
GitHub側の最新情報だけ取りたい。
まず何が変わったか確認したい。
pull
git pull
GitHub側の変更を取得して、今いるbranchへ反映したい。
毎回必ず、
fetch
↓
pull
と2回実行しないといけないわけではありません。
単純に最新化したいだけなら git pull でも構いません。
一方、複数PC運用では、
まずGitHub側の状況を見てから動きたい
ことがあるため、
git fetch
を先に使う意味があります。
12. feature branchの続きをWindowsでやる場合
Macでは、
feature/header
で作業してpush済み。
Windowsにはそのbranchがまだないとします。
まず、
git fetch origin
して、
git branch -a
を確認します。
GitHub側に、
remotes/origin/feature/header
が見えているなら、そのbranchをローカルへ作ってswitchできます。
明示的に行うなら、
git switch --track origin/feature/header
です。
Gitの switch はbranch切替用のコマンドで、remote-tracking branchから追跡branchを作成する用途にも使えます。 Git
その後、
git status
を確認して、Windows側で続きを始めます。
13. すでにWindowsにもfeature branchがある場合
以前Windowsでも、
feature/header
を使っていたなら、
git switch feature/header
で切り替えます。
そのうえで、
git pull
です。
upstreamが正しく設定されていれば、対応するremote branchから更新されます。Gitではupstream branchが pull や push の既定対象として利用されます。 Git
14. Windowsで作業を再開する
ここまで来れば、
Macで作業した最新状態
↓
GitHub
↓
Windows
がつながっています。
あとは通常どおり作業します。
git status
で状態を確認しながら修正し、
git add .
git commit -m "Continue header update"
git push
です。
15. Windows→Macも同じ
逆方向でも考え方はまったく同じです。
Windows
↓
commit / push
↓
GitHub
↓
Mac
↓
fetch / pull
↓
作業再開
つまり、
Mac用のGit運用
Windows用のGit運用
を別々に覚える必要はありません。
GitHubを間に置いて、
作業終了時にpush、別PC開始時に同期
と考えるだけです。
16. 「どちらのPCが最新版か」を覚えない
複数PC運用で分かりにくくなるのは、
Macの方が新しかったっけ？
Windowsで昨日修正したっけ？
と人間の記憶で管理し始めることです。
そこで、
GitHub上の状態を正本にする
と決めます。
作業PC
↓
commit
↓
push
↓
GitHubを最新にする
別PC
↓
fetch / pull
↓
GitHubに合わせる
こうすると、
MacとWindowsのどちらが最新版かを考える必要がありません。
17. 2台で同じbranchを同時に進めない
技術的には可能ですが、一人で複数PCを使う場合は、
Macでfeature/headerを編集
同時に
Windowsでもfeature/headerを編集
という状態は避けた方が分かりやすいです。
基本は、
Macで作業完了
↓
commit / push
↓
Windowsで同期
↓
続きを開始
です。
同じ変更箇所を2台で同時に進めると、あとでconflictなどの原因になります。
conflict自体は別のトラブル編で扱う方が分かりやすいです。
私が使う最小フロー
作業を終えるPC
git branch --show-current
git status
git add .
git commit -m "変更内容"
git push
作業を始めるPC
git status
git branch --show-current
git fetch origin
git pull
必要なら対象branchへ、
git switch feature/example
またはremote branchから、
git switch --track origin/feature/example
です。
まとめ
複数PCでGitHub作業を続けるときは、
初回
→ clone
作業終了
→ status
→ commit
→ push
別PCで開始
→ status
→ branch確認
→ fetch
→ pull
と整理すると分かりやすいです。
重要なのは、コマンドを丸暗記することよりも、
作業終了時にGitHubへ渡し、作業開始時にGitHubから受け取る
という流れを固定することです。
これで、
Mac
↕
GitHub
↕
Windows
の複数PC運用がかなり整理しやすくなります。