GitHubで2人の共同作業をしたときのコマンド一覧（記事の付録）

この付録は、記事「PCを2人で共有する最適解｜GitHubプルリクエスト」で、当方の開発担当者がテストとして1回通したときに実際に打ったコマンドの記録です。記事は社長・管理職向けにコマンドを省いたので、手を動かす担当者向けにここへまとめました。

前提：WindowsのPC、コマンドプロンプト、Git for Windows。保管場所の名前とアカウント名は、見本の名前（<アカウント名>・<保管場所>）に置き換えています。uv と pytest を使う行は、当方の仕組み（Python）に固有の手順です。

1. 相手を共同作業者として招待する（ブラウザ・招待する側）

GitHubで保管場所を開き、Settings → Collaborators → Add people の順に進みます。途中で本人確認の画面が出るので、2段階認証のコードを入れます。

招待する前のCollaboratorsの画面。書き込めるのは自分だけと表示されている — 招待する前。「Only you can contribute to this repository（書き込めるのはあなただけ）」と出ています。

相手のユーザー名を入れて招待すると、一覧に「Pending Invite（承認待ち）」と出ます。相手にはメールが届くので、Accept invitation を押してもらいます。

招待したあとの一覧。承認待ちと表示されている — 招待したあと。相手が承認すると「Pending Invite」が消えます。

2. 相手のPCに保管場所を複製する

置きたい場所の1つ上のフォルダで実行します。git clone がその中に新しいフォルダを作るためです。最初の1回は、ブラウザでGitHubへのログインを求められます。

cd C:\c_works
git clone https://github.com/<アカウント名>/<保管場所>.git
cd <保管場所>

当方の保管場所では、続けて次の2つを1回だけ実行します。1行目は、保管場所に入れてある仕掛け（一度に50ファイル以上の記録や、秘密のファイル名の記録を止める）を有効にする設定です。2行目は、プログラムが使う部品を入れる命令です。

git config core.hooksPath tools/githooks
uv sync --extra dev

OneDriveやDropboxで同期しているフォルダは避けます。Gitの管理用のファイルが同期とぶつかって壊れることがあるためです。

3. 自分用のブランチを作る

名前は「種類/何をするか」の英小文字にしています（例：feat/＝新しい機能、fix/＝直す、docs/＝文書）。日本語や空白は使いません。

git switch -c feat/git-team-demo

4. 自動テストを流す（当方の仕組みに固有）

uv run pytest -q

複製した直後に流すと、共有PCでは通っていた9件が通りませんでした（5 failed・4 errors）。原因と直し方は、記事の「なぜ自分のPCで動くのに、相手のPCでは動かなかったのか」にあります。直したあとは、最後の行が 2374 passed, 56 skipped になりました。

5. 変えたファイルだけを確かめて記録する

先に、何が変わったかを見ます。新しいフォルダはフォルダ名だけで表示されるので、中身まで見るときは -uall を付けます。

git status
git status -uall

変えたファイルだけを名指しで追加して、記録します。git status の案内に git commit -a と出ますが、使いません。変わったファイルを全部まとめて記録してしまい、意図しないものが混ざるためです。

git add src/genba_agent/publishing/pages.py demos/construction-photo/out/.gitignore demos/construction-photo/out/sorted/placements.json
git commit -m "fix: clone した先でも通るよう、JS 検査を Volta 経由でも動かし、工事写真の仕分け結果を追跡に入れる"

CRLF will be replaced by LF という警告は、改行の形を保管場所の決まりにそろえるという知らせで、問題ありません。

6. GitHubへ送る

初めて送るときだけ -u を付けます。2回目からは git push だけで同じブランチへ送れます。

git push -u origin feat/git-team-demo

7. プルリクエストを作る（ブラウザ・出す側）

送った直後なら、保管場所の画面に Compare & pull request が出ます。出ないときは Pull requests → New pull request で、base に main、compare に自分のブランチを選びます。Create pull request を2回押すと作られます。

プルリクエストを作る前の比較の画面 — 比較の画面。「Able to merge」は、正式な版とぶつかる変更が無いという意味です。

8. 自動テストの結果を見て、直す

プルリクエストの画面の下に、GitHub上の自動テストの結果が出ます。当方では、GitHubへ送るたびに自動テストが動く設定（.github/workflows/tests.yml の on: [push]）を前もって用意してあります。

自動テストが通らなかったときの表示 — 通らなかったとき。「All checks have failed」と出ます。

直すときは、同じブランチでもう一度記録して送ります。プルリクエストに自動で加わり、自動テストも流れ直します。

git add tests/test_construction_photo_demo.py
git commit -m "test: Windows のフォントが無い環境では、工事写真デモの画像を作るテストを飛ばす"
git push

テストの結果の画面にある Re-run jobs は、古い記録のテストをもう一度流すボタンです。直した記録を送れば新しいテストが自動で始まるので、押す必要はありません。

3回目の記録で自動テストが通ったプルリクエストの画面 — 3回目の記録で通ったとき。記録ごとに×と✓が並びます（フォントが無いため飛ばしたテストは除きます）。

9. 確かめて、正式な版に入れる（ブラウザ・確かめる側）

Files changed で変わった中身を読み、Merge pull request の横の ▼ で Create a merge commit を選んでから、Merge pull request → Confirm merge を押します。

マージの方法を選ぶメニュー — いちばん上の「Create a merge commit」を選ぶと、いつ誰がどのプルリクエストで入れたかが履歴に残ります。

マージが終わった画面 — 終わると紫の「Merged」になります。**Delete branch** で作業用のブランチを消せます。

10. 両方のPCで正式な版を最新にする

作業を始める前に、毎回これをします。相手の変更を取り込んでから始めるためです。3行目は、正式な版に入った作業用のブランチを手元から消す命令です（入っていないブランチは、Gitが消すのを止めます）。

git switch main
git pull
git branch -d feat/git-team-demo

11. つまずいたところ

起きたこと	原因	どうしたか
一部の自動テストが、相手のPCでだけ中身の無い失敗をした	`where node` で node が2つ見つかり、先に見つかるのが切り替え道具（Volta）の中継役だった	その画面だけ `set "PATH=C:\Program Files\nodejs;%PATH%"` で本物を先にすると通ったので、受け渡しを一時ファイル経由に直した
GitHub上でだけ1件が通らない	GitHub上では文字に色を付ける記号が出力に混ざる	手元で `set GITHUB_ACTIONS=true` を付けて流すと同じように落ちたので、記号を取り除いてから比べる形に直した
`git status` に新しいファイルがフォルダ名だけで出た	新しいフォルダは、まとめて表示される	`git status -uall` で中身を1件ずつ確かめてから追加した

操作は、AI（Claude Code）に1つずつ聞きながら進めました。それでもコマンドを打つ場面は残るので、エンジニア以外の人に同じことを頼むなら、Gitの操作をAIに任せる仕組みを先に用意するほうが現実的です。