必要なコマンド表
ブランチを作るために、以下のコマンドを使います。よく使うので、覚えておくと便利です。表は横にスクロールできます。
| コマンド | 説明 |
|---|---|
| git clone | リモートリポジトリをローカルに複製する |
| git remote -v | リモートリポジトリの URL を確認する |
| git checkout -b ブランチ名 | 新しいブランチを作成してそのブランチに切り替える |
| git pull origin main | リモートの main ブランチの変更を取得してマージする |
| git push origin ブランチ名 | ローカルの変更をリモートリポジトリにプッシュする |
| git fetch origin | 最新のリモートリポジトリ情報を取得（変更は適用されない） |
| git merge origin/main | 取得した main ブランチの変更を現在のブランチに統合する |
| git status | 現在の変更状況を確認する |
| git log --oneline | コミット履歴を簡潔に表示する |
| git diff | コミット間の差分を確認する |
| git add | 変更をステージングする |
| git commit | ステージングされた変更をコミットする |
| git revert | 特定のコミットを打ち消す新しいコミットを作成する |
| git reset --hard | ローカルの状態を強制的にリセットする（※慎重に使用） |
upstream
upstream はチーム開発や fork ベースの開発 でとても重要な概念ですが、状況によっては不要です。チームリポジトリに直接招待された場合、fork ではなく、GitHub 上で collaborator（共同編集者）として招待されている場合は、upstream（チームの本番リポジトリや fork 元のリポジトリ） は不要です。
それでは、実際の作業手順を見ていきましょう。
1. clone する
リモートリポジトリをローカルに複製します。フォルダを作成しなくても git clone した際に自動的に作成されます。
xxxx は、実際のパラメーターを入力してください。
2. リモートリポジトリの情報を表示する
リモートの URL をチェックして、プッシュできるか確認します。これでリモートリポジトリ (origin) の URL を確認できます。これはリモートリポジトリに影響を与えないので実行しても問題ないです。
3. ブランチ作成
ブランチ dev を作成。main ブランチから dev を作成し、そのまま dev に移動します。
ブランチ戦略の補足
| ブランチ名 | 説明 |
|---|---|
main | 本番環境にデプロイされるコードを保持する安定版 |
dev | 開発中のコードを集約する統合ブランチ。複数の feature/* ブランチの作業結果がここにマージされる |
feature/* | 新機能や改善点を開発するためのブランチ。例: feature/login-page |
wip/* | 作業途中（Work In Progress）の個人ブランチ。レビュー前の状態などに使用 |
ブランチ名は意味のある名前にすると、他の開発者が意図を把握しやすくなります。以下は一例です。
| ブランチ名 | 内容 |
|---|---|
feature/login-form | ログインフォームの実装 |
fix/typo-in-readme | README の誤字修正 |
refactor/user-service | ユーザーサービスのリファクタリング |
hotfix/crash-on-startup | 緊急でアプリ起動時のクラッシュ修正 |
chore/update-dependencies | 依存パッケージの更新 |
wip/signup-validation | サインアップバリデーション作業中（未完了） |
ブランチ名に日本語は避け、スラッシュ（/）でカテゴリと作業内容を区切るとわかりやすくなります。
4. main の最新の変更を dev に統合
main ブランチに新しい変更があった場合、それを dev ブランチに取り込む必要があります。作業ブランチが古い状態だと、マージ時にコンフリクトが起きやすくなります。リモートには影響せず、ローカルで最新の main を dev に統合するだけです。
4. dev に移動
5. dev の変更をリモートにプッシュ
ローカルで作業していた dev ブランチを GitHub 上のリモートにも作成します。他のメンバーと共有するには、リモートに push する必要があります。push はリモートに影響を与えますが、この段階ではまだ本番コードには関係しません。
6. main の最新の変更を取得（安全な方法）
もし main に新しい変更があれば、以下の方法でコンフリクトを避けるのが良いです。
git fetch origin→ main の最新情報を取得（変更を適用しない）git merge origin/main→ main の変更を dev に統合
git pull と git fetch + git merge の違い
git pullは裏でgit fetchとgit mergeを自動で実行します。- そのため、コンフリクトがある場合に自動でマージが始まり、対処しづらくなることがあります。
git fetch→git mergeの手順であれば、最新の変更内容を事前に確認できるため、落ち着いてマージ作業ができます。
例えば以下のように作業できます。
6. 作業用のブランチを作成（例: 新機能追加）
作業ごとに新しいブランチを作ることで、機能ごとの変更を管理しやすくなります。dev や main に直接コミットせず、安全に開発を進めるための基本です。ブランチ名には何の作業かが分かるような名前をつけるのが望ましいです。
7. 作業完了後、dev にマージ
作業が終わったら、dev ブランチに変更を統合します。このタイミングで、他の作業ブランチの変更と合わせて検証できます。push することで、チーム全体の dev 状態を最新に保てます。
よくあるトラブルと対処法
コンフリクトが起きた場合は、該当ファイルに以下のような記号が表示されます。
どちらの変更を残すか選択して、ファイルを編集した後 git add して git commit しましょう。
- 万が一、間違って
mainに直接 push してしまった場合は、revertを使って変更を取り消すことができます。
または、履歴ごと戻す場合は git reset を使います（注意して使用してください）。
8. GitHub で PR を作成し、main に統合
GitHub 上での PR のポイント
- PR を作成するときは、以下のような情報を含めるとレビューがスムーズです。
- 何を変更したか（What）
- なぜ変更したか（Why）
- 動作確認内容（How）
例：
- PR の作成後は、必要に応じて Reviewers や Assignees を設定しましょう。
PR 文章を提出する
一応、Notion などでPR依頼を伝えます。
マージされたら
Github の、main > view all branches に移動。Your braches から削除します。
補足：CLI に不慣れな方向けのアドバイス
コマンドライン操作に不安がある場合は、以下のような GUI クライアントもおすすめです。
- GitHub Desktop
- Sourcetree
- Tower
また、現在の状態を確認したいときは以下のコマンドが便利です。
作業の前後にはこれらのコマンドで状況を把握すると、トラブルを避けやすくなります。
