個人でGit, GitHubを効果的に使う
そのままmainブランチにコミット&プッシュを無心で繰り返して、ある程度Gitを使えた気になっている私のような人いますか?いないか...
薄々このままでは良くないと思っていたので、ここらで自分のためになるようフローとステップをまとめ、効果的かつ実務でも使えることを目指します。
細かいことはどうでもいいって方は作業フローセクションまですっ飛ばしてください★
現在の運用方法について
mainブランチのみで直接commit & pushはダメか
- 個人プロジェクトでは短期的には問題ない。
- シンプルで学習コストが低い。
欠点
- mainを常に安定・デプロイ可能な状態に保つことができない可能性。
- 実務でのブランチ運用・プルリクエストの文化に慣れる機会の損失。
- 複数デバイスでの開発、将来的に他人が入ると混乱しやすい。
実務での考え方
- チームでは通常、mainブランチは障害の少ない状態に保つ。
- ブランチを使い、プルリクエストでレビューしてからmainにマージする運用が求められる。
ここまでのまとめ
個人開発でmainブランチにcommit & pushは許容されるが、習慣としてfeatureブランチ + プルリクエストを身につけておく方が将来役に立つ。
Gitの基本
GItは2種類ある
ローカルGit = 自分のPC内の変更履歴ノート(コミットで一時記録、プッシュでリモートに反映)
GitHub = リモートの安全なバックアップ & 公開場所(プルリクで履歴管理・レビュー)
ブランチは「新しい開発の場」。mainブランチは常に安定版に保つ。
小さな単位でコミット → 意味あるコミットメッセージ → 頻繁にpush(レビューが楽になる)
今はコミットもAIにやらせていいと思います。「適切にコミットして」と投げるだけでコミットしてくれます。
個人開発向け戦略
普段はfeatureブランチを使い、GitHub上で自分に向けたプルリクエストを作って軽くセルフレビュー(差分確認)してからmainブランチにマージする。マージ後はfeatureブランチを削除(ローカルGitからも削除)し、新しくfeatureブランチを切りそのブランチで作業をする。
ブランチ
main
常にデプロイできる安定版。直接変更はしない。
feature/xxx
新機能やタスクごとに作る。特別なことはありません。ブランチ名を次のようにするだけです。
例:
- feature/login-ui
- feature/contact-form
- feature/user-profile
- fix/form-validation
- refactor/header
個人開発では、まずは main と feature/xxx だけで十分です。
マージ方法
まずは普通にmerge
簡単。詳細なコミット履歴が残るため緊急時にRevertしやすい
慣れてきたらsquash merge
プルリク内のコミットが一つのコミットにまとめられ綺麗。
main の履歴を綺麗に保てます。
運用ルール
main直接コミット禁止 → 変更は全てfeatureブランチをプルリクエスト経由でmainにマージして反映させる。
使用ツール
今どきわざわざCUIを使ってコマンドで操作する必要もないのでGUIに頼ります。
古臭いことを言ってくる奴にはおビンタをお見舞いしましょう🌹
VS Code
もはやこれだけで解決。
左サイドバーのソース管理で差分確認/ステージ/コミット/プッシュ可能。
さらに、ブランチ作成/ブランチ切り替えまでも対応しています。
GitHub
プルリクエストの作成、セルフレビュー、CI確認、マージはGitHubウェブ上で行います。
VS Codeで作業し、GitHubでPull Requestを確認してマージする。
この役割分担にしておくと分かりやすいです。
作業フロー
前提としてGit、GitHubの登録は完了しているものとします。
最近の個人開発では、Next.jsやViteなどで先にローカルにプロジェクトを作り、その後GitHubへ公開する流れが多いです。
そのため、まずはローカルで作ったプロジェクトをGit管理するところから始めます。
初回だけやること
- VS Codeでプロジェクトを開く
- Source ControlからGit管理を開始する
- 最初の変更を確認する
- initial commit する
- GitHubへ公開する
これでローカルのプロジェクトとGitHub上のリモートリポジトリの接続が完了です。
ざっくり手順
ここからが本題です。
- main を最新にする
- feature ブランチを作る
- VS Codeで作業する
- Source Controlで差分を確認する
- ステージしてコミットする
- GitHubへPushする
- GitHubでPull Requestを作る
- 差分とCIを確認する
- main にマージする
- ローカルの main を更新する
- 次の作業も main から新しいブランチを作る
つまり、普段やることはこれだけです。
mainを最新にする
↓
作業用ブランチを作る
↓
作業する
↓
差分を見る
↓
コミットする
↓
Pushする
↓
PRを作る
↓
確認してmainへマージする
↓
mainを更新して次のブランチへ
具体手順
先に初回だけやることの具体手順を記します。
不要な方は1. mainを最新にするまで読み飛ばしてくだいさい。
0-1. VS Codeでプロジェクトを開く
開いてください。
0-2. 初回準備:VS CodeでGit管理を開始する
- VS Codeでプロジェクトフォルダを開く
- 左サイドバーのSource Controlを開く
- Initialize Repository をクリック
- 変更ファイル一覧が表示されることを確認する
この時点では、まだGitHubには公開されていません。
ローカルでGit管理が始まっただけです。
0-3. 初回準備:最初の変更を確認する
Source Controlに表示されたファイルを確認します。
最低限、以下が含まれていないか確認します。
.env
APIキーやパスワードを含むファイル
node_modules
不要な生成ファイル
問題なければ、変更をステージします。
0-4. 初回準備:initial commitする
- Source Controlで変更をステージする
- コミットメッセージに initial commit と入力する
- Commit をクリックする
0-5. 初回準備:GitHubへ公開する
- Source Controlの Publish Branch または Publish to GitHub をクリック
- GitHubへのサインインを求められたら案内に従う
- Public / Privateを選択する
- GitHub上にリポジトリが作成されることを確認する
個人開発でまだ公開したくない場合は、Private を選んでおくと安心です。
後から変更できるのでどちらでもいいです。
1. mainを最新にする
- mainを最新にする
- VS Code左下のブランチ名をクリック
- main に切り替える
- Source ControlからPullする
2. featureブランチを作る
- VS Code左下のブランチ名をクリック
- Create new branch を選択
- ブランチ名を入力する
- Enterで作成する
ブランチ名の例。
- feature/login-ui
- feature/contact-form
- fix/form-validation
- refactor/header
作成後、左下のブランチ名が作成した作業用ブランチに変わっていることを確認。
3. VS Codeで作業する
作業用ブランチ上でファイルを編集します。
作業前に、左下のブランチ名が main ではなく、作業用ブランチになっていることを確認します。
4. 差分を確認する
- Source Controlを開く
- 変更されたファイルをクリックする
- 差分を確認する
最低限、以下を確認します。
- 意図した変更だけか
- 関係ないファイルを触っていないか
- .env や秘密情報が含まれていないか
- 不要なデバッグコードが残っていないか
5. ステージしてコミットする
- コミットに含めたい変更をステージする
- コミットメッセージを入力する
- Commit をクリックする
コミットメッセージはAIに作ってもらうと感覚が掴めます。
変更の意図がわかるようにしましょう。
6. GitHubへPushする
- Source Controlから Push をクリックする
- 初回は Publish Branch と表示される場合がある
- GitHub上に作業ブランチが作成されることを確認する
7. Pull Requestを作る
- GitHubのリポジトリページを開く
- Compare & pull request をクリックする
- baseが main になっていることを確認する
- compareが作業用ブランチになっていることを確認する
- タイトルと本文を入力する
- Create pull request をクリックする
8. セルフレビューする
- PRページの Files changed を開く
- 差分を確認する
- CIがある場合はChecksを確認する
問題があれば、VS Codeで修正して、同じブランチにコミット・Pushします。
9. mainへマージする
- PRページで Squash and merge を選択する
- コミットメッセージを確認する
- マージする
- Delete branch が表示されたら、不要なリモートブランチを削除する
10. ローカルのmainを更新する
- VS Codeに戻る
- 左下のブランチ名から main に切り替える
- Source ControlからPullする
これで、GitHub上でマージした内容がローカルの main に反映されます。
11. 不要なローカルブランチを削除する
- VS Code左下のブランチ名をクリックする
- マージ済みの作業ブランチを探す
- 不要なブランチを削除する
12. 次の作業ブランチを作る
次の作業を始めるときは、必ず main から新しいブランチを作ります。
- main に切り替える
- Pullする
- 新しい feature ブランチを作る
- 次の作業を始める
Discussion