12
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

うわっ…私のgitflow、古すぎ…?

Posted at

プロローグ

「アジャイルでやってます」っていう現場にジョインしたら単になにもルールを設けず適当にやっていて[1]、gitflowでやろうよって言う前に手順を確認しようと検索してみた。そしたら検索トップに引っかかったのがJiraで有名なAtlassianで、「Gitflowはレガシーだけど歴史的な理由で紹介するね」と書いてあった。

[1]: 運用ドキュメントにはgit add git pushなどの実コマンドが数行書いてあるだけだった。

用語

開発の中心となるブランチ、Subversion時代はtrunk、gitではmasterが主流だったけど、ポリコレの関係でgithub/gitlabともにmaster->mainになったのでこの記事ではmainを使います。

トランクベースワークフロー

じゃあ今のトレンドはなんなのかというとトランクベースワークフローらしい。でもこれってCI/CDがちゃんと整っていて、マージされる度にテストが走って、日に数回デプロイするような環境ならともかく、メンバーには新人もいてコードレビューしてからマージしたいような通常の開発では厳しすぎない?

Google Cloud アーキテクチャセンターにはもっと丁寧な説明があった。

改善方法なども書いてあって「トランクベースならうまく回る」っていうよりも「トランクベースで回す努力しよう」みたいな感じに見える。っていうかこれってモノレポだとビルドに時間かかるし、いつでも適用できる手法じゃないよね。っていうかatlassianのはポジショントーク的なblog postって感じだし。

GitHub Flow

そういえばGithub flowってあったよね、っと思って確認するとmainブランチと修正用のブランチしかなくて、形式的にはトランクベースとかわらなさそう。ただトランクベースはポリシー的にもっと誰でもmainにマージできるイメージなのかな。

git flow

だいたいみんなが知ってるやつ。developブランチを中心に機能追加はfeature/xxxを作ってレビューしてdevelopにマージ、リリース様にrelaseブランチにマージしてテストが終わったらmainにマージする。バグ修正はhotfixブランチを切って直接mainにもdevelopにもマージできる。

これちゃんとやると結構面倒なので、developを中心に機能別にfeatureを切って、リリース時はmainにマージしてリリースしたらreleaseタグだけ打つ(releaseブランチは切らない)、hotfixはgit flowに準拠してもいいし、急ぎでないならfeatureの一つとして扱って次のリリース時マージに対応、みたいなのが楽でいい。

Draft (WIP)

今までWIPっていた手法がある。。gitlabではWIP:とついていればマージできず、かつWIP:のON/OFFトグルボタンまであったのだが、久々に行ったらWIP:の代わりにDraft:を使うことになっていた。一応議論もあった。
https://forum.gitlab.com/t/why-the-change-from-the-wip-merge-request-prefix-to-draft/40239

でも単にGitHubに合わせたんだろう。
https://github.blog/jp/2019-02-19-introducing-draft-pull-requests/

GitHubのプルリク(pull request)はGitLabではマジリク(merge request)になる。でもこういうのは開発プロセスの用語として統一して欲しい。開発してて「WIPでプルリクだしといて」と言えばマージ前レビュー用と作業中タスク管理の意味で使えていたのに、Draftだと広い意味で下書きになってしまうじゃないか。まあそのうち慣れるか。

用語はともかくこれはなにかというと、プルリクの頭にDraft:とついていればこれはまだマージ待ち状態じゃないですよ、という印だ。ならプルリクを作らなければいいじゃないかと思うかもしれないが、実際には機能完成前にレビューしてほしい事は結構ある。また、スクラムでやってて「じゃあこのタスクは俺が担当ね」となった時にDraft:でプルリク作ってしまえば他のメンバーも進捗が把握しやすい。たまにこれをやるにはgitで空コミットを許可しないと、という話になることがあるけど、別に修正箇所にコメント一箇所だけいれたり空行削除してコミットしてもいいので、空コミット許可は必須ではない。ちゃんとコミットコメント管理するチームならrebaseでコミットまとめたりするだろうし。

まとめ

てなわけでgit-flow省力版 + Draft運用にする。チームへの周知用ドキュメントにするつもりで書き始めたけど脱線が多いので書き直しだなこれは。

git develop draft flowとでも呼ぶかな。誰か粋な名前つけてくれるといいけど

12
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?