職場でプロジェクトの説明をされた時に
Git flowではなくGitHub flow
みたいな説明されたのですが、Git flowとGItHub flowに違いがあるのか？となりました。
こうしたブランチ戦略に対して、あまり深く考えてなかったので、調べてみました
Git flowはdevelop,master,feature,release,hotfixと細かく役割を分けてブランチを切って管理します。
これに対してGitHub flowはシンプルで、masterとfeatureブランチだけです。
使い分けは？
上記の記事は本当にdevelopブランチが必要なの？という切り出しから要件を考えて、ブランチ戦略を決めています。
Gitも最近になって主流になってますが、正直、そこまで考えてませんでした。
Source Tree使ってる慣れでGit flow一択でした。
記事で指摘されているように手元で動くかだけなので、実はずっとdevelopブランチのままでmasterブランチにマージしてないリポジトリがあったりします。
耳の痛い話でした。
プライベートで運用する程度であれば、わざわざブランチを切らなくて、直接コミットして行けばいいのです。
職場の同僚でも直接masterにブランチしてると言い合っていたのですが、わざわざブランチを切ってマージすればいいとは限らず、ありと言うことでしょう。
といっても大幅な改造を行う時にはブランチを切って、やり直ししやすい状況をつくるべきです。
Source Treeからはプルリクエストしない
前職ではあまりPull Requestしたことがありませんでした。
Backlogでチケット管理していたので、そこからPull Requestです。
Source Treeから出来ないものか？と思ったのですが、やはりPull Requestは、GitLabなりBacklogから行った方が良さそうですね。
そのブランチ戦略、どう書くの？
で、それらの肝心のブランチ戦略ですが、私のように口伝だったら人数が少ないケースだったら、良いですが、書いてくれないと毎回説明しないとならないじゃんと。
どう記載すればいい？とGitHubを探ってみました。
exment/ReadMe.md at master · exceedone/exment · GitHubより
GitHub - hanami/hanami: The web, with simplicity.より
