Git+GitHubでブランチを切って開発する流れ

実際の本番環境でGit+GitHubでブランチを切って開発していく流れをメモ。

記事中で使っているスクショはSourceTreeです。

1.cloneする

プロジェクトが手元にないなら、cloneコマンドでコピーします。

git clone cloneしたいGitHubプロジェクトのURL

2.issueを立てる

GitHubでissueを立てます。

例えば「◯◯という機能を追加したい」みたいなイシューを立てます。

 

本来ならここで

  • 「このイシューは自分が担当します」
  • 「このイシューはお前がやれ」

みたいな感じで、誰かを「アサイン」します。

▲Assigneesで担当する人を指定する

3.ブランチを切る

例えば、mainブランチからブランチを切る場合は、まずmainブランチに移動します。

git checkout main

 

次にブランチを切ります。

例えば、feature/◯◯という名前でブランチを切る場合は以下のように書きます。

git branch feature/◯◯

 

切った後は、ブランチを切り替えます。

git checkout feature/◯◯

 

ちなみに以下のコマンドを打つと、ブランチの作成と切り替えを同時に行えます。便利。

git checkout -b feature/◯◯

「どのような名前のブランチを切ってどのように開発していくか?」は開発現場によって違うので何とも言えないですが、少なくとも今回の例みたいに「mainからブランチから直接ブランチを切って開発する」みたいな現場はほとんどないと思います。

有名なブランチの開発戦略としては「Git-flow」などがあるみたいです。

参考Git-flowをざっと整理してみた | DevelopersIO

4.開発をすすめる

feature/◯◯を解決するためのコードを書きます。👨‍💻👨‍💻👨‍💻

5.add

Gitにステージングします。

例えば、更新したファイルをすべてステージングする場合は、以下のように書きます。

git add .

6.commit

Gitにコミットします。

git commit -m "◯◯という機能を追加した close #◯"

 

ここでclose #◯みたいに書くと、GitHubで立てたissueをcommitと同時に閉じることができます。

詳しくは以下のページなどを参照ください。

参考GitHubでcommitにissueを紐付ける | エンジニアもどきの技術メモ

▲この場合、#9がコミット番号

7.push

GitHubにpushします。(以下のどちらかを実行する)

git push origin feature/◯◯
git push origin HEAD

(HEADを付けると「現在チェックアウトしているブランチに対応するリモートブランチに自動的にpushする」みたいな意味になります)

8.GitHub上でプルリクエスト

GitHub上で「mainブランチにマージしてくれや!」を意味するプルリクエストを出します。

▲GitHubのページに行くと「プルリクエスト出す?」みたいに表示されてるはずなので、これを押す。

 

押すと、以下のような画面が表示されるので、どのブランチに対してプルリクエストをだすのか決めてOKを押します。

▲おそらく、GitHubで設定している「デフォルトブランチ」がデフォルトとして設定されているはず・・・

 

ちなみにプルリクには以下のページに書いてるあるように、2種類あるので好きな方を選びます。

参考プルリクエストとドラフトプルリクエストの違い

 

実際の開発現場の場合は

  • Reviewers:レビューする人
  • Assignees:プルリクエストの内容を対応した人・対応する人

という2つを設定します。

詳しくはこちらの記事↓が参考になります。

参考GitHubでのプルリクエスト活用方法まとめ – ICS MEDIA

9.GitHub上でマージ許可

※この作業は通常、コードをレビューする人(偉い人)がやります

プルリクエストがきたら、コードのレビューをしたのちにOKだったら「mainブランチにマージするのを許可するぅ!」ボタンを押します。

これでマージされます。

▲これはリポジトリの管理者的な人しか押せない

10.mainブランチに切り替える

以下のコマンドでmainブランチに切り替えます。

git checkout main

11.mainブランチをpullする

  • ローカルのmainブランチ ←古い
  • リモート(GitHub)のmainブランチ ←新しい

という状態になってしまっているので、これを同じにするために以下のコマンドを打ちます。

git pull origin main

12.ローカルブランチを削除する

feature/◯◯のローカルブランチは、すでにpush済みなので不要。

なので以下のコマンドで削除します。

git branch -d feature/◯◯

13.リモートブランチを削除する

feature/◯◯のリモートブランチもすでにmerge済みなので不要。

なので以下のコマンドで削除します。

git push --delete origin feature/◯◯

ちなみにプロジェクトの設定でAutomatically delete head branchesの設定をONにすると、マージされると自動的にマージしたブランチを削除できるみたいです。

参考GitHubでマージしたブランチを自動で削除する簡単な方法 – Beeeat’s log

 

これで完了です。

個人開発の場合

おそらく、個人で開発する場合は

  • mainブランチだけで作業する
  • devブランチを切る → 開発 → add&commit → ローカルでmerge してしまう→ mainをpushする

のどちらかで開発するのが一般的なのかなと思います。

 

例えば、WordPressの有名テーマである「Cocoon」は、前者の方法で開発されているようです。

参考になる動画

以下の動画がめちゃくちゃ分かりやすいのでオススメです。

この方が所属していた開発現場の流儀では「このコードでどうですか?」とお伺いを立てた後、「ここはこうした方が良いと思う」みたいな指摘をもらったら、それをローカル環境のコードに反映させて、git rebase  -i コマンドでコミットを一つにまとめてgit push -f origin HEADで強制コミットする・・・みたいなルールだったらしいです。

(この方も仰ってるように、rebaseを使わない会社もあると思われますが)

 

 

※間違いや補足等あれば、指摘していただけるとうれしいです!🙇

Git
スポンサーリンク
この記事を書いた人
penpen

1991生まれ。
元アフィリエイターなWEBエンジニアです。うんちコードなら書けます。
お仕事あれば下さい。カジュアル面談も気軽に誘って下さい。

技術スタック:TypeScript/Next.js/Express/Docker/AWS

penpenをフォローする
penpenをフォローする
penpenメモ

コメント

タイトルとURLをコピーしました