【初学者向け】個人開発におけるGit,GitHubの現場を想定した開発フロー

はじめに

僕は今転職に向けてポートフォリオを作成しているのですが、
GitとGitHubをより実際の現場を意識した運用にして開発ができればいいなと思いました。

調べてみると、組織のメンバー構成や開発規模によって異なるようですが
主に現場で使われてそうなのがGitフローとGitHubフロー。

参考：【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう

上記のフローを踏襲して実際の現場を意識しつつ、GitHubのプルリクエストをミックスした
オリジナルの管理フローを作成しました。

参考：[実践] はじめてのPull Requestをやってみよう

この記事の対象者

• ポートフォリオ作成中の方
• エンジニアへの転職を目指して勉強中の方
• GitとGitHubは学習済みで使い方はある程度知っている方

プログラミング学習歴

• プロゲート
• ドットインストール
• Railsチュートリアル

※学習を始めて数ヶ月の初学者です。

ブランチを切るところからGitHubにpushするまでの7ステップ

まずブランチを以下の3つに分けて開発をしていきます。

• masterブランチ
• developブランチ
• developから派生させたfeatureブランチ

masterブランチは常にデプロイできる状態に保つ必要があるため、
基本的にはdevelopブランチとfeatureブランチで作業します。

主な流れ

1. ローカルのdevelopブランチを最新の状態にする
2. developブランチからfeatureブランチを切る
3. コードを書いて実装していく
4. 実装完了
5. GitHubにプルリクエストを立てる
6. masterブランチにpushする
7. ローカルのfeatureブランチを削除する

詳しく書いていきます。

step1: ローカルのdevelopxブランチを最新の状態にする

まず、以下のコマンドでローカルのdevelopブランチを最新の状態にします。

git pull origin develop

万が一developブランチが古い状態だった場合
実装が終わっていざmergeやpushした時に予期せぬコンフリクトが発生する可能性があります。
個人での開発で発生することは少ないと思いますが、あくまでこれは実践を想定したフローなので
この作業は忘れずに必ず行います。

step2: developブランチからfeatureブランチを切る

実務経験がないと、どのタイミングでブランチを切ったらいいかわからないという方が多いと思います。
現場では機能単位でブランチを切って作業していると仮定して
今回は投稿機能やメッセージ機能など実装したい機能ごとにブランチを切っていきます。

git checkout -b "feature-ブランチ名"

また、ブランチ名は「そのブランチで何の作業をしているのか」が分かるようにつけることを意識しています。
「いい感じの名前が思いつかない」という方は以下のサイトを参考にしてみてください。

参考：codic: プログラマーのためのネーミング辞書

これは日本語で入力された単語や熟語をもとに、プログラミングに適したいい感じのネーミングに翻訳・生成してくれるサービスです。
ブランチ名の他にもコミットメッセージや変数名で迷った時にも使えるのでオススメです。

step3: コードを書いて実装していく

ここで最も意識することはGitにこまめにコミットすることです。
これに関しては2つのメリットがあると思っています。

1. 躊躇せずに手を動かせる
2. 転職時のアピール材料になる

個人的には①のメリットが大きいと思ってます。
初学者のうちは何度もエラーにはまったり、下手したらコードが壊れることもあると思います。
こまめにコミットをしていれば万が一の時でも簡単にリセットしてやり直るので、
結果、躊躇せずに手を動かせます。
逆にコミットの粒度が粗いとそうはいきません。

②に関しては、ある会社の採用担当をされている方から
「応募者のポートフォリオを見る際はコミットの粒度が細かいかもチェックしている」と聞いたことがあります。
他の応募者との差別化にもつながるはずなので、面倒くさがらずこまめにコミットするようにしています。
どこでコミットしたらいいか分からないという方は以下の記事が参考になります。

参考：【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた

step4: 実装完了

実装が終わったらdevelopブランチに移動して

git checkout develop

featureブランチをmergeします。

git merge feature-ブランチ名

僕の場合はこの後メンターさんにレビューして頂くのでmerge後にGitHubにプルリクエストを立てます。
また、レビューには実装前と実装後の2パターンのコードが必要になるため、
ここではまだdevelopブランチはGitHubにpushしません。

プルリクエストを立てる必要がない方は次のstep5は飛ばして大丈夫です。
あるいは試しにプルリクエストを立ててみると勉強になると思います。

step5: GitHubにプルリクエストを立てる

featureブランチをGitHubにpushしてプルリクエストを立てます。

git push origin feature-ブランチ名

この時点でGitHubではdevelopブランチが実装前、featureブランチが実装後の状態になっているので
developブランチとfeatureブランチの差分をレビューしてもらいます。

プルリクエストの承認をもらえたら次のstep6へ、
ダメだったらfeatureブランチのコードを修正して再度GitHubにpushします。

step6: masterブランチにpushする

プルリクエストの承認がもらえたら、masterブランチにpushします。

masterブランチに移動して

git co master

featureブランチをmasterブランチにmergeしてから

git merge feature-ブランチ名

GitHubにpushします。

git push origin master 

developブランチに移動してこちらも同じくGitHubにpushします。

git co develop

git push origin develop

step7: ローカルのfeatureブランチを削除する

最後にここまで作業してきたfeatureブランチを削除します。
ブランチが乱立してしまい「このブランチっていつ作ったやつだっけ」となるのはあまり良くないのでこの段階で削除しておきます。
※リモートのfeatureブランチはプルリクエストをmergeしたタイミングで削除しておきます。

git branch -d feature-ブランチ名

ブランチの削除に関しては以下の記事を参考にしてください。

参考：Gitでローカルブランチを削除する

最後に

いかがだったでしょうか。
以上が普段僕がポートフォリオを作成する上で運用している管理フローです。

PF作成や学習の初段階から実践を意識したGit、GitHubの使い方をマスターすることが
必要不可欠だと感じたため、今回の記事を書きました。

初学者の方々の参考になれば幸いです。