masterを基本とするって話とGithub flowがいいじゃんって話 個人メモ

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm 現代のGitでどこまでできるのかためしていないけど、5年前くらいまではGitでのログ表示というのは大量のブランチをいいかんじにフィルタリングする能力というのがなくて、大量のブランチでもいいかんじにやるのはMercurial一択だった。GitはGUIにしろなんにせよリッチなフィルタをあきらめている 2019-10-25 22:14:12 きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm 仕事はシンプルな方がいい Gitではブランチを野放図にできない となると、master一本にいかによせるのかというのがキモになるっていう。 で、それでこまらないというか。 で、master一本がうまくいかないときは(同一タイムゾーンでの)仕事が下手な可能性を示すシグナルになるんだよ。 2019-10-25 22:18:14

[kwkmsj]

粘り強く丁寧な議論がすごいなー

[ono_matope]

ええ…？これはチーム全員がモブプロするから実質レビュー者がいない場合に限りfeature branchを切らないという話？そうれあれば理解できるけど、それ以外の前提では…。integrated workflowとやら、ググっても何も出てこず謎

[t_yamo]

リモート中心だと作成途中のPRへのコメント等で会話するので1本化はつらい。あと実装途中の物が担当者の手元にしかないともしものときに組織が困るのでうちはビルド通らない状態のをpushしてもらうのにfeature使ってる。

[tumo300-500]

diff に対してコメントが付けられて、それを後から振り替えれるという一点だけでもプルリクの優位性ありそうだけどなー / 「ここからここまでが問題Xへの対応」とか後からどう確認するんだろう。必ず squash するとか？

[kappaseijin]

trunk based developmentだと割り込み作業で切り替えるときはどうするんだろう。stash?

[inamem9999]

話する前の自己紹介(常に最新のものだけをリリースするor次期バージョンの作り込みの最中に旧バージョンを改修したものをリリースすることがある、など)が必要なような気が

[naglfar]

ブランチを切らない方法は前提がまったく違うので参考にならん。 @ikeike443 氏の表現に学びたい。初手から「フィーチャーブランチ切らないなんておかしい！」って言いがちだったりするよね。

[radiocat]

チームの状況にもよるのだろうけど、Gitなら当然PR運用するよね的な考え方じゃなくて自分たちに合ったやり方を選べるよねという話なのかな。

[odakaho]

ひとつのプロジェクトが開発者個人に紐づくような、小規模リポジトリが沢山あるんじゃないかな？それだとPR作ってもまともにレビュー出来る人いないから実質master素通しじゃねってなる。

[rryu]

スタンドアロンのアプリケーションとライブなウェブアプリでは管理方法が全然違ったりするのでアレだが、ブランチを作る前に実装するものについて特に話し合わないというのが共通しているのが不思議。

[toaruR]

せめてdevelopくらいないと不安になるわー

[gachapining]

常に信頼できるチームメンバーでハッカソンし続けているようなスタイルなのかな。何となくわかるけど、それが嵌るのは非常に稀有なケースに感じるなー

[coppieee]

自動テストさえしとけばバグってもすぐ修正すればいいだけだし、コミットの打ち消しも出来るんだから、別にmaster一本でもいいんじゃね

[peketamin]

発表を待ちたい

[koogawa]

master に直push って個人開発でもやらないな…

[crexist]

branch戦略の話かと思いきやmasterにいきなりpushするという話だった。個人開発ならわかるんだけども。。。(個人的にはprivateな開発でもPR投げるスタイルなのであまり賛同しない)