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

脱ブランチファースト https://irof.hateblo.jp/entry/2019/10/25/113652 をよんでおもったことをかいていたら、いくにんかが率直な意見をたくさんなげてくれてちょっと明確になった気がします。
17
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

ちなみに、私はGitにおいてこの7年間でmasterブランチ一本を常に貫いてます。これは研修でも常にそう。(個々の対応は教えるとしても)

2019-10-25 21:56:16
きょん@アジャイルコーチ、システムアーキテクト @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
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

これはアジャイルにおける全員同席が非効率だとおもうときには、アジャイルな組織になれていないというシグナルになるのと似ている。 原則やプラクティスがなぜそこまでシンプルであるのかというのは本当にかんがえる必要がある。 端的にいえば、現実から目をそらすなって話。

2019-10-25 22:20:25
はるじっく @haljik

gitの。今のところmaster一本化では良い影響しか経験してない

2019-10-25 22:21:58
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

ソフトウェア構成管理パターンをよんだり、歴史をしらべたり、なぜブランチをつくりたいのかとかをなぜなぜ分析するとわかるとおもうんだけど、そういうのは、結局仕事を非同期におこなうことで、生産性向上やチャレンジの可能性をあげたいっていう思想があるのがおおい。

2019-10-25 22:23:33
MegumiNakagami @meg_nakagami

現実的に develop 一本で、リリースする時に master にまんまマージって感じで5年ぐらいやってきたけど、どうだろう。 できる限りシンプルにすべきってのは同意で、 master 一本でも問題ないとは思うんだけど、なんか怖い。 何が怖いのかはわかんない。

2019-10-25 22:25:10
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

本当にそれにYesっていえるならいいんだ。あとはそれ以外の理由でも「それが必要ないくらいにスキルアップするのは、絶対にやりたくない方向だ」っておもうならいいんだ。でもそうじゃないときにまで本当に「主観に任せるルール」を増やすべきかは考えるべきだ。っていうのが持論。これはなんでもそう

2019-10-25 22:25:47
MegumiNakagami @meg_nakagami

構成管理でしょうがないのはわかるんだけど、日々の作業で細かくブランチわけていろいろやっても、その「いろいろ」のコストは、そこから得られるメリットを上回らないんだよねぇ。

2019-10-25 22:26:41
MegumiNakagami @meg_nakagami

ブランチをわけて頑張ってると git に詳しくなるんだけど、プロダクトを作るために仕事してるのであって、きれいなコミットログを作るために仕事してるわけじゃないしねぇ。

2019-10-25 22:28:12
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

メンヘラソフトウェア構成管理ジジイなので、いくらでも話がつきない。このへんでやめておこう。。。

2019-10-25 22:29:17
MegumiNakagami @meg_nakagami

あと、しっかりブランチわけで、かっちりプルリク投げて、丁寧に修正して・・・ってやったところで、コードが良くなるわけじゃないんだけど、そういうことをやることで満足しようとする人が出てくる。 『本来の仕事ではないけどやんなきゃいけないこと』があると、それをやることに逃げるんだよな。

2019-10-25 22:31:29
MegumiNakagami @meg_nakagami

とりあえず develop に push しろ、何を変更したか口頭で説明しろ。 これで十分なはずなんだよな。 これが出来ない人はどうブランチをこね回したところでプロダクトには貢献できない。 そういう人の成果物を安全に取り込もうとする作業は無駄なコストでしかない。

2019-10-25 22:33:21
MegumiNakagami @meg_nakagami

それを自分にも適応すると、 master 一本でいいじゃねぇか、となるのはわかる。 うーむ。

2019-10-25 22:34:05
アラトリウス @kFrontier

これなんだよな。でもこれで困らん時に、何の理由もなくGitに乗り換えるためのパワーが無いし、かけられんのよね。

2019-10-25 22:38:24
oohira @oohira

あぁ、自分がモヤってたのはこれだ。うまく言語化されていて腑に落ちた twitter.com/kyon_mm/status…

2019-10-25 23:01:38
omanuke @omanuke

master一本にこだわる理由はあまりよくわからぬ twitter.com/kyon_mm/status…

2019-10-26 03:10:04
いけださんからいいツッコミ
Takafumi Ikeda @ikeike443

@kyon_mm これって、リリースブランチみたいな生存期間の長いブランチを複数持たないという意味でおっしゃってます? 開発のたびにフィーチャーブランチはまめに切る前提ですよね? 全くブランチを使わない、というふうにも読めるので、確認ですー。

2019-10-26 07:48:51
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@ikeike443 原則の話ですけどFeatureブランチも切らないです。リリースしたくないならFeatureトグルできるように設計します。テスト環境もプッシュ単位でスポットインスタンスにデプロイするかどうかを選ぶ感じです。 困るのは画面で大きな改修をするときで、それはブランチになりがちかも。

2019-10-26 08:09:37
Takafumi Ikeda @ikeike443

@kyon_mm ええっ。。テストもレビューもしないんですか? 単純に使い方が間違ってるように聞こえます。

2019-10-26 08:12:35
Takafumi Ikeda @ikeike443

@kyon_mm すいません。ちょっと全然理解できないです。。かなり変わったことを主張されてる気がするので、ブログなどにまとめられるといいかもです。誰も気づいてない新しい観点に着目されてるのかもですが、ツイートだけだとそれが分からないので。。

2019-10-26 08:14:20
Takafumi Ikeda @ikeike443

@kyon_mm そのためにブランチを切ってプルリクエストをするからですね。

2019-10-26 08:14:50
残りを読む(71)

コメント

Yeme @yer_meme 2019年10月26日
最早git使う意味が無い気がするっス。他のツールなり自製なりする方がいい気がするっスね。
3
フシハラ @Fushihara 2019年10月26日
それで回ってるなら全く問題ない。使い方は自由だ。
0
kumonopanya @kumonopanya 2019年10月26日
gitが単純なバックアップ装置になっている。もっといろんな魅力的な引き出しがあるけど使い方を知らない。シナリオのない洋ゲーRPGのように。
3
🦐私がエビです🦐 @I_AM_EBI_DESU 2019年10月26日
アジャイルコーチ、システムアーキテクト (自称)
2
おろろ @fYe39CoQsPrbZVK 2019年10月26日
こんなんチームにおったら草むしりでもしてもらうしかないわな。説明するだけ時間の無駄
2
たるたる @heporap 2019年10月26日
1人でやるかチームでやるかの違いだと思う。
0
k9cycle @__hage 2019年10月27日
何事も教条的なのはいかんよ。作業前に絶対ブランチ切るマンも master ブランチ以外絶対に使わないマンもね。何事も教条的なのはいかんと教条的に思ってるんだけどその辺はごめんね。一人で作業するときも実験的な実装をやってみるときはブランチ生やしてから作業しますね。なんかいいものができたら master にマージするし、失敗だと思ったら master に戻って実験ブランチを消します。C で必要とあればバシバシ goto を使うマンからのお知らせは以上です。ダイクストラおじさんには内緒だよ。
1
たるたる @heporap 2019年10月27日
私はどちらかというとマスター一本ですけど、マスターでも実験に失敗したら履歴を戻ればいいので、ブランチを切る必要がないんですよね。複数の実験や、実験と本編を同時進行で行う場合はブランチを切りますけど。
1
たるたる @heporap 2019年10月27日
チームでやる時は履歴を戻すことができないので、何かある度にブランチを切るしかないと思います。
0
もりのあさ @forenoonM 2019年10月27日
Takafumi Ikedaさんのヒアリング能力本当にすごい。見習いたい。
3
パンダは肉食獣 @j_inbar 2019年10月27日
自分も基本master一本だな。教科書的なブランチの話が分からないわけじゃ無いけど、個人的な見解としてはブランチ切ったりする必要がある≒ 開発と研究/調査/設計の切り分けが出来てない and/or コミュニケーションの破綻が近い ぐらいの目安で、仕事としてならば、目的に対するアプローチの点検のシグナルだと思うぐらい。
0
パンダは肉食獣 @j_inbar 2019年10月27日
j_inbar 大規模開発とかOSSとか関係者が大量に居て、下手すりゃ昼夜問わず世界中で開発をするとかなら、話別だろうけど。
0
undo @undosystem 2019年10月27日
最初はmasterだけとかありえないと思ったけど、Trunk-Based Developmentを起点に色々調べたら結構ありだと思えた。でもそれを実現させるための前提条件がなかなか厳しい。
1
alan smithy @alansmithy2010 2019年10月27日
趣味のコーディングをひとりでやるならmasterでもいいが、共同作業でfeatureなりブランチ切らないのはまずいよ
1
🦅あえとす⛩️ @aetos382 2019年11月1日
結局、具体的にどういうプロセスを回しているのか、よくわからんまとめ…
0