今日は、git-flowの基礎のき / branchをどこでどう切ってどうするの？！についてアウトプットします。
こんにちは。駆け出しコーダーのharuです。
＊わたしについて＊
2歳0歳の育児をしながら、22時〜2時にプログラミングを独学しています。
2020.5.11~学習スタート
2020.8.10~実務でコーディングしています
まだHTML/CSS(SCSS)/jQuery のよわよわです。これからもっと知識をつけていきたく、インプット・アウトプットを続けています。
普段から学習していてわかったことや、気付きをログに残しています。
※認識の間違っている箇所があれば、ご教授いただけるとうれしいです！
git-flowの基礎のき / branchをどこでどう切ってどうするの？！
何を見ても理解できなかったgit-flowの基本のきをもりけん先生(@terrace_tec)に教えていただいたのでアウトプットします。
・どのbranchをどこで切るの？
・branchの名前、どうしたらいいの？
・どこで何をしてどうなるの(´；ω；`)ハテナ
となっていた過去のわたしに向けて書きます。
git-flowって何？
git-flowとは、branchの管理方法のモデル・ツールのことです (どちらも指す)
Vincent Driessenさんが考案したもので、元記事 “A successful Git branching model” を翻訳したものを発見しました。ありがたい。今回のブログは、こちらも参考にさせていただきました。
git-flowで管理すると、複数の人と開発を進める時に、branchを誰がみてもわかりやすい状態に保つことができるので便利です。
<!– メモ –>
そもそものgit/ GitHubについては、いくつかアウトプットをしているので、よろしければどうぞ！
git-flowのbranchの種類
わかりやすい git-flowのイメージ図を拝借しました（敬礼）
(引用：【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう)
このように、複数のbranchを切って、開発〜テスト〜リリースまでを進めていきます。
branchの種類について軽くまとめます。
メインブランチ
メインブランチは、「master」「develop」の2つです。
- master: 【大元】リリースする完成ソースを管理
- develop: 【開発中の大元】開発中の最新のソースを管理
developに集まる開発ソースが安定してリリースできる状態になったら、masterブランチにマージします。
サポートブランチ
サポートブランチは、「feature」「release」「hot-fix」の3つです。
- feature：実際に実装をしていく時に使うブランチ
- release：実装がおわったものをテストサーバーで実際にテストするブランチ
- hot-fix：masterソースに見つかったバグを早急に修正するブランチ
なので、普段実装をしていく時に使うのはfeatureブランチです。ここで、機能ごとにfeatureブランチを切って、実装が終わったらdevelopにマージします。
git-flowの流れ
流れを簡単に説明します。図を再掲します。
(引用：【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう)
masterからdevelopを作成する
git checkout master git checkout -b develop
developを作るのは、プロジェクトがはじまった最初だけです。
developからfeatureを作成する
次に、カレントディレクトリがdevelopの状態で、featureブランチを切ります。
git checkout develop git checkout -b feature(-機能名など)
featureブランチの命名に関しては、調べたところさまざまな意見がありました。特に必ずこれというものはないようです。
- feature-機能名/*
- feature/yyyymm-機能名/*
- feature/yyyymm-{案件名}/*
- feature/yyyymm-{案件名}/{issue番号}/*
など。
※しかし、featureはdevelopにマージすると消すことが多いため、それならpushしても別にいいのでは？という意見もありました。→こちら
featureで機能が完成したらdevelopにマージする
git checkout develop git merge --no-ff feature名 git branch -d feature名 git push origin develop
–no-ffを使うことで、開発に使ったコミットをひとまとめにしてマージすることができます。
developからreleaseブランチを切る
git checkout develop git checkout -b release-1.0
releaseでは、テスト環境でのテストや、この後のリリースのためのバージョン設定も行います。
※branch名は、release-x.xのように バージョンを入れることが多い。
releaseブランチからmasterとdevelopにマージ
masterにマージさせることで、リリース済みとなる。
git checkout master git merge --no-ff release-1.０ git tag -a 1.０
※developブランチでもreleaseをマージする。＝developは常に開発中の最新のコードを保管する場所だから
git checkout develop git merge --no-ff release-1.0
リリース後にバグが発見されたら、hot-fixブランチを切って対応する
git checkout -b hotfix-1.1 master
・ver.を1つ増やす
・バグ修正後に1つ以上のコミットを行う
・その後にhot-fixブランチを終了させる
git checkout master git merge --no-ff hotfix-1.1 git tag -a 1.1
・最後に、developにもマージさせて終了
git checkout develop git merge --no-ff hotfix-1.1
なぜ、リリース後のバグ修正はhot-fixブランチで行われるのか？developではダメなのか？
→developで作業している人がその作業をしながら、別の人が素早いバグの修正を並行して進めることができるから
あとがき
まだまだ軽い内容ではありますが、Git-flowの仕組みを知ることができました。
Thanks：師匠「もりけんさん」(@terrace_tec)
もりけんさんのHPはこちら
