Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々

Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

[Songmu]

blogged.

[Keisuke69]

自分はdevelopmentブランチ用意するパターンが多い。“「リードエンジニアにレビューしてもらってマージしてもらう」はアンチパターン”とのことだけど同意する反面で悩ましいなとも思う

[k2wanko]

ハードウェアなのかサーバーなのかスマホアプリなのかライブラリなのかとかで変わりそう

[kobito19]

結果的に同じことやってるのにそれぞれでスタンスが異なるのがモニョる

[turanukimaru]

作りかけのコードやテストが十分でないコードを push してレビューと言うか相談していいかが悩ましい。ただ Go だと Java やってた頃に比べて設計の話をする現場が少ない。結合度を下げる！と言ってコピペする人が多い…

[oakbow]

ベースブランチへの追従は必ずrebase使うけどあとはだいたい同じかなあ。prのスピードはそのくらいが理想だとは思うし分割もやるけど数日かかる場合も結構ある。マージボタンはレビュアーが押してる

[n314]

自転車置き場の議論楽しいよね。ただ前提として人数とか体制とかを先に知りたいかなあ。プログラムに詳しくないオーナーに変更点を説明してからリリースする必要があるという要件があるだけで全て変わりそうだし。

[takamii228]

Tag(Release) Requestの実装を望む声がここにもあった。

[uxlayman]

賛否の前にここに上がった議論点を全部理解できる人が少ないという問題がある。Gitは無意味に複雑すぎる

[hush_in]

"「リードエンジニアにレビューしてもらってマージしてもらう」はアンチパターン"

[civitaspo]

粒度を図る単位に時間を使うのわかりやすくてよさそう > ブランチに1日分の作業量以上積み重ねているのにpull requestを出せなかったら黄色信号。

[tkmkg8m]

“泥臭いログ含めて残っていた方が問題調査に役立つ”とか“読み手の負担を考えてコミットをきれいにするのは間違いなく良い心がけ。ただ、頑張りすぎる必要もない”とか激しく同意

[himikko]

、

[maruware]

全部同意。Draft pull requestはあんまりやれてない。

[for-my-internet-demo]

あんまりrebaseに意味感じる運用してないなあ

[itinagi]

自分のスタンスに近かった

[MonMonMon]

“当然自分だけが開発しているfeatureブランチに対してのみ使う 「後でamend/rebaseするかもしれないから」とfeatureブランチをpushせず手元で温められる方が嬉しくない”

[sigwyg]

“「自分が押したマージが本番に出ていく」という体験をしてもらう”　これは確かに良いかも

[hamaco]

大体同じ感じだなー。言語化してまとめられてるのよい。

[oasis440]

“--force-with-lease”

[tchssk]

“レビューワー等読み手の負担を考えてコミットをきれいにするのは間違いなく良い心がけ” スムーズにレビューして欲しかったら気配りすべきだし、そうしないならレビューに時間がかかるのを受け入れるべき

[kappaseijin]

レビューとPRマージで権力勾配が起きるの分かる。それぞれ得手不得手あるだろうけどいつも同じ人が指摘しているとそうなりがち

[moto_2010]

“モブプロをすればレビューは不要か？ そうは思わない” 分かる。モブプロしてレビューなしにしたら今まで指摘された・していたものが漏れる

[tk_musik]

モブとレビューの話同意。モブ導入時にレビュー不要をリードタイム向上根拠としてしまうと罠にハマって偉い人が個別アサインに戻す。TDDと同じで品質確保のためですの方が。スピードは絶対負けではないが状況次第。

[yimajo]

“同じ見落としをしてしまい、バグを生む可能性がある”<-同意。実際あった。コードレビューは念のための確認プロセスとして必要だったりもするけどそのプロセスが雑にやられることもあるけども

[callirhoe08]

ほぼ同意。言語化に感謝です。

[hujuu]

“ブランチに1日分の作業量以上積み重ねているのにpull requestを出せなかったら黄色信号。2日分以上溜めてしまったら立ち止まったほうが良いかもしれない”

[rjge]

“基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良い” ほんこれ。オーナーシップもあるけど、最初のうちは気持ち的な慣れも必要だと思ってるのでマージは本人がやるようにしたい派

[tengo1985]

PRは一日の作業分、PRは出した当人がマージなど

[wyukawa]

なるほど＞“「自分が押したマージが本番に出ていく」という体験をしてもらう”

[ryuzee]

言語化されててありがたい

[eller]

GitHubにtag requestは無いですが、Release Drafterがその役割を担うものとして紹介されることありますね。

[sotet]

、

[damedog]

案外こういうまとまったものがない気がするので指標にしたい。