masterを基本とするって話とGithub flowがいいじゃんって話 個人メモ
-
- いいね！1
きょん＠アジャイルコーチ、システムアーキテクト
@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
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
ソフトウェア構成管理パターンをよんだり、歴史をしらべたり、なぜブランチをつくりたいのかとかをなぜなぜ分析するとわかるとおもうんだけど、そういうのは、結局仕事を非同期におこなうことで、生産性向上やチャレンジの可能性をあげたいっていう思想があるのがおおい。
2019-10-25 22:23:33
MegumiNakagami
@meg_nakagami
現実的に develop 一本で、リリースする時に master にまんまマージって感じで５年ぐらいやってきたけど、どうだろう。 できる限りシンプルにすべきってのは同意で、 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
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:14:20