git の develop ブランチは必要なのか、またはリリースtagについて

songmu @songmu

feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど

Kazunori Otani @katzchang

Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。

小野マトペ @ono_matope

Githubはfeatureブランチをmasterにマージする前にデプロイしてるのか…下手に真似すると怪我しそう。 / “中の人に聞いたGitHub flowの本当の使い方 - Qiita” htn.to/4oW5GSrJJv

小野マトペ @ono_matope

モチベーションは理解できたが、developとmasterがまるで別物になってしまうのが良くない。任意のfeatureブランチを検証環境にデプロイする仕組みを整えた方が建設的ではないか。 / “GitFlowをやめて本番リリースが楽になった話 - Qiita” htn.to/2XcjhTZczy

小野マトペ @ono_matope

やっぱfeatureの検証（QA）はfeatureブランチからるべきだな。developerやmasterはテストするとこではないぞいという

songmu @songmu

最近はdevelopブランチは要らないんじゃないか、と思うようにはなってきてて、developからmasterにマージされたら自動deployされるのではなくて、masterにfeatureブランチ直接マージしていって、masterにタグが打たれたら自動deployという形が良いのではないかと思いつつある

songmu @songmu

何故かというと、developからmasterにマージするとコミットハッシュが変わってしまうので、そこでまたテストとビルドが走ってしまうのは時間の無駄だし、動作確認を事前にdevelopでやっている場合、別のハッシュでリリースするのであれば、その確認の意味が薄れてしまうというのもある。

ymmt @ymmt2005

> masterにfeatureブランチ直接マージしていって、masterにタグが打たれたら自動deploy neco の CD の片方がこれ。tag -> CI -> deb package build -> pull で自動デリバリ

songmu @songmu

ここに対する障壁としてgit-pr-releaseの便利さがあって、pull request上でリリース差分を確認できたり、pull requestをリリース証跡にできるのは有用なんだよな。

songmu @songmu

GitHubはあるコミットハッシュに対するRelease Request(Tag Request)みたいな機能を提供して欲しい。 twitter.com/songmu/status/…

songmu @songmu

git-pr-releaseに代わる、Release issueを登録できるツールがあれば良いのかねぇ

songmu @songmu

pull requestが便利だから、release engineeringもそれでやってしまっているけど、Git本来的にはそれはtagでやるべきなんだろうなー

散歩しただけ @side_tana

tagでリリース絶対いいな(テストが2回走る問題辛いよねという立場です)

songmu @songmu

@side_tana あと、ステージングで動作確認したものと、本番に出ていくものが、厳密には異なるっていうのもちょっと気持ち悪いよね

散歩しただけ @side_tana

@songmu わかります

songmu @songmu

多分コミットハッシュでビルド作るのもイマイチという話もあって、例えばgit archiveのtar玉のハッシュ値をビルドのURIに使えば、masterブランチにマージしても同じ成果物を使わせることができる、とかはある。

らっきー @lucky_rand0

@songmu @0918nobita 質問です。developブランチなしの運用の場合、hotfixを切りたいときはどうすれば良いとお考えですか？ masterの最新ではなく、タグ打ちされたところから切れば良いのでしょうか？

songmu @songmu

マージコミット作りたい派ではあるんだけど、メインラインにffマージできるのであれば、テストとビルドをやり直す必要はないってのはあるんだよな

songmu @songmu

@ara_tack @0918nobita 普通にfeatureブランチと同じようにブランチ作ってマージしてリリースするか、masterに直接コミットしてテスト通って動作確認終わったらタグ打ってリリースで良いのではないでしょうか。masterがリリースtagより進んでいて、リリースしたくないものがある場合は、(続きます

songmu @songmu

@ara_tack @0918nobita 一旦revertしてしまうか、前回のリリースタグ地点からブランチングして、そこで修正を作ってそこにタグを打ってリリースした後にmasterにマージすると、などが考えられると思います。ただ、masterにマージしたのにリリースできないものがあるという状況をそもそも作らない方が良いとも言えます

songmu @songmu

hotfixブランチって、複雑なブランチングルールの上で生まれざるを得なかったワークアラウンドルールみたいなところがあって、本来要らないものでもあるとも思う

らっきー @lucky_rand0

@songmu ありがとうございます。 今のチームではリリース前にまとめて動作確認しているので、不具合修正だけ動作確認してすぐに出したい時はどうすべきか気になって質問いたしました。masterにリリースできないものがあるのがよくないという話は同意するとともに耳が痛い話でした。

songmu @songmu

featureブランチをffマージしつつ、いざとなったらそこで入った複数のコミットをまるっとrevertできる、みたいな機能もGitHubにあると嬉しいのかなぁ

柴崎優季 @shiba_yu36

@songmu develop作らない時、hotfixの難しさはあるかもしれないですね

songmu @songmu

@shiba_yu36 確かにその難しさはあって、別のリプでも回答しています。ただ、緊急修正はhotfixがあろうが無かろうが難しい問題で、hotfixブランチはdevelopを並走させるからこそ生まれてしまった徒花でもあると思います。