GitとGitHubを学び始めると、clone、branch、commit、push、mergeといったコマンドを個別には理解できても、「実際の開発ではどの順番で使うのか」が分かりにくいことがあります。
この記事では、小さなMarkdownプロジェクトを例に、GitHub上のリポジトリをPCへ取得し、作業用branchで変更し、commitしてGitHubへpushし、最後にmainへmergeするところまでを一連の流れとして確認します。
重要なのはコマンドの暗記ではありません。各段階で、PC内のGitリポジトリがどう変わったのか、GitHub側がどう変わったのかを区別して理解することです。
1. 今回確認する全体フロー
今回の流れは次のとおりです。
GitHub上のリポジトリ
↓ clone
ローカルリポジトリ
↓ branch作成
作業用branch
↓ 編集
working treeに変更
↓ add
staging areaへ登録
↓ commit
ローカル履歴へ記録
↓ push
GitHubへbranchを送信
↓ mainへ切替
↓ merge
作業内容をmainへ統合
git clone はリポジトリを新しいディレクトリへ複製し、remote-tracking branchを作成して初期branchをcheckoutします。git push はローカルのbranchやその他のrefと必要なobjectをremoteへ送ります。git merge は指定したcommitの変更を現在のbranchへ取り込みます。
2. GitHubからcloneする
最初に、練習用リポジトリをGitHubから取得します。
git clone <repository-url>
cd <repository-directory>
状態を確認します。
git status
git branch -a
git remote -v
この時点でどこに何があるか
- GitHub側：元のremote repositoryが存在する
- ローカル側：repository、working tree、Git履歴、
originというremote設定が作られる
cloneしただけではGitHub側の内容を書き換えていません。GitHubからローカルへ取得した段階です。
3. 作業用branchを作る
mainを直接編集せず、作業用branchを作ります。
git switch -c feature/readme-update
現在のbranchを確認します。
git branch --show-current
ここでは feature/readme-update と表示されれば準備完了です。
なぜbranchを分けるのか
mainを安定した状態に保ったまま変更を進められるためです。変更が失敗してもmainの履歴と分離して考えられます。
この時点では、作ったbranchはまだローカルにしかありません。
4. ファイルを編集する
例として README.md に1行追加します。
## Practice
Git/GitHub basic workflow practice.
編集後に確認します。
git status
git diff
git statusでは変更されたファイル、git diffではまだstageしていない変更内容を確認できます。
この段階の変更はworking treeにあり、まだcommit履歴には入っていません。当然、GitHubにも反映されていません。
5. addしてcommitする
変更内容を確認したらstaging areaへ登録します。
git add README.md
git status
続いてcommitします。
git commit -m "Update README for Git practice"
履歴を確認します。
git log --oneline --decorate -5
commitしたらGitHubにも反映される？
まだ反映されません。
commitはローカルリポジトリの履歴を更新する操作です。GitHub側へ送るには次のpushが必要です。
6. branchをGitHubへpushする
初回はupstreamを設定しながらpushすると分かりやすくなります。
git push -u origin feature/readme-update
Git公式ドキュメントでは、git push <remote> <branch> がローカルbranchをremoteへ送る基本形で、-u / --set-upstream は成功したbranchにupstream情報を設定します。
確認します。
git branch -vv
git status
ここで初めて、作業用branchとそのcommitがGitHub側にも存在する状態になります。
注意：安易にforce pushしない
git push --forceは通常の安全確認を無効化し、remote側のcommitを失わせる可能性があります。練習段階では、必要性を説明できないforce pushは使わない方が安全です。
7. mainへ戻ってmergeする
作業用branchの変更をmainへ取り込みます。
まずmainへ切り替えます。
git switch main
状態を確認します。
git status
問題がなければmergeします。
git merge feature/readme-update
履歴を確認します。
git log --oneline --graph --decorate --all
git mergeは現在いるbranchへ、指定したbranchの変更を取り込む操作です。したがって、feature/readme-updateをmainへ入れたい場合は、先にmainへ移動してからmergeします。
mainが作業branchの祖先であれば、通常は新しいmerge commitを作らずfast-forwardになります。履歴が分岐していれば、競合がなければmerge commitを伴う統合になる場合があります。
8. merge後のmainをGitHubへ送る
ここは混同しやすいポイントです。
ローカルmainへmergeしただけでは、GitHub上のmainはまだ更新されていない場合があります。
確認します。
git status
git branch -vv
remote mainへ反映するなら、必要に応じて次を実行します。
git push origin main
これでローカルmainの新しい履歴がGitHub側へ送られます。
9. ローカルとGitHub側を整理する
一連の操作を整理すると次のようになります。
| 操作 | 主に変化する場所 | 意味 |
|---|---|---|
clone | ローカル | GitHub等のremote repositoryを取得する |
switch -c | ローカル | 作業branchを作って切り替える |
| ファイル編集 | working tree | 作業内容を変更する |
add | staging area | 次のcommitへ入れる変更を選ぶ |
commit | ローカルrepository | 変更を履歴として記録する |
push | GitHub側 | ローカルの履歴をremoteへ送る |
merge | 現在のローカルbranch | 別branchの履歴を統合する |
この区別を理解すると、「commitしたのにGitHubが変わらない」「mergeしたのにremote mainが更新されない」といった混乱を減らせます。
10. 失敗しやすいポイント
branchを確認せず編集する
編集前に次を確認します。
git branch --show-current
git status
add前に内容を確認しない
不要なファイルをcommitへ含めないよう、git statusとgit diffを確認してからstageします。
commitとpushを同じ操作だと思う
commitはローカル履歴、pushはremoteへの送信です。役割を分けて理解します。
mergeする向きを逆にする
git merge <branch> は「現在いるbranchへ <branch> を取り込む」です。merge直前に現在branchを確認します。
merge前に未整理の変更を残す
Git公式ドキュメントでも、merge前に自分の作業を良好な状態にし、ローカルでcommitしておくことが推奨されています。未commit変更がある状態で複雑なmergeを始めると、競合時の復旧が難しくなることがあります。
11. まとめ
Git/GitHubの基本フローは、次の一本道として覚えると整理しやすくなります。
clone
↓
branchを作る
↓
編集する
↓
status / diffで確認する
↓
add
↓
commit
↓
push
↓
mainへ切り替える
↓
merge
↓
必要ならmainをpush
重要なのは、今の変更がworking tree、staging area、ローカルrepository、GitHubのどこに存在するのかを常に意識することです。
コマンドを入力した直後にgit statusやgit logで状態を確認する習慣を付けると、Gitは暗記科目ではなく「状態を観察しながら履歴を操作する道具」として理解しやすくなります。
参考資料
- Git公式
git clone: https://git-scm.com/docs/git-clone - Git公式
git push: https://git-scm.com/docs/git-push - Git公式
git merge: https://git-scm.com/docs/git-merge
