2024年Gitワークフロー再考 | フューチャー技術ブログ

春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で

[benok]

コミット整理したりrebaseしてからpushするのは同意だけどsquashしちゃうのもったいない。レビュー時に個別コミットが役に立つ事多く(インデントずれで差分ロジック読めない時とか)レビュワー可読性重要。goとかは..(文字数

[kazuhooku]

github上でしかレビューしないならfeature branchのrebase不要だし悪だし、commit追う場合でもrebaseされると意味がわからなくなることがあるので、常にmainをfeature branchにmergeでいい派。squash mergeもよほど大規模じゃなければ不要

[baronhorse]

みんなsquash好きだな。フィーチャーブランチでかくなると読みづらくなるので mergeコミット作る方が好みだわ

[vegnpomn]

rebaseはハマればきれいなんだけど「コンフリクト発生時の処理がrebaseの方がちょっと面倒」は軽く見てはならないと思う。Gitで事故る唯一のポイントがより複雑になるってのはrebaseを捨てる理由として十分なほど重い

[hase0510]

マージコミット派だけど、レビュー指摘によるちょっとした修正が独立したコミットで残る意味は薄いと思うので、GitHubがfixup!を見てうまいことやるようになってくれるといいな。

[tengo1985]

キレイになるのはうれしいけど、マージコミットあっても困らないでしょ派。ローカルではきれいすればいいけど。

[love0hate]

他人に迷惑がかからなければ各々好きにすれば良い派。

[work996]

色々突っ込まれてるけど、「現代のGit使いに求められるメンタルモデル」ってのが一番あれだな…。この会社ではこの考えに反する社員はGit使い失格扱いなのかな。かなりのエコーチェンバーが形成されてそうで草。

[prjpn]

なんだろう、このツールに毒されてる感は。

[aruiha_shikashi]

rebaseしてforce pushするプログラマーに村を焼かれた過去があるので決して分かりあえない宿命

[psne]

ローカル限定でsquashはたくさんやる。authorとツリーの情報は大切にしたい(OSS方面では特にauthorは大事にしたい。)

[matsubobo]

こういう運用ルールのところでは働けないな。と思った。 https://twitter.com/matsubokkuri/status/1778292653467291803

[tattyu]

"気軽にPull Requestに含まれる1コミットだけを取り消すといったこともできなくなります。"プロジェクトによってはあかんのでは。。。

[eichisanden]

Pull Request以外はマージコミットを作らない、レビュー指摘はブランチの本流に入れないのは好みだが、Rebase操作を強要することと1 PR = 1 Commitの粒度を徹底するのが1番難しそう（スキルがまちまちな複数人での開発を想定）

[wordi]

自分はローカルでロジックの段取り付くごとに細切れコミットしてpush時に機能毎のコミットにまとめるってやり方だからsquash結構使う

[seal2501]

Squash は昔トラブったのでもうやらないな… / メンバーのgit 理解度に合わせて改善していくしかない。理想系見せてこれで行くぞ！だとトラブる

[progrhyme]

そういう流儀もある、と。

[sds-page]

GitHub道のお作法。そのうちいくつもの流派に分かれていくんだろう

[nin_nikun]

古のvim使い、emacs使いに近いものを感じる

[ksyundo]

“rerere.enabled”

[softstone]

本気で変更意図が分からないときはPR単位ではわからなくてオリジナルのコミットのログを見たいんだけどそういう時はコミットログ読んでもわからないので、結局どうでも良い気がする。レビュアーへの気持ちだけ考えろ

[atsushieno]

ここの開発アプローチだと巨大すぎるトピックブランチのマージ問題を解決できない

[dorapon2000]

“git config rerere.play trueが入ったおかげで、長期間生存し、developからなんども変更を取り込むようなケースが楽になりました。”

[marshi]

個人的にはコミット単位での履歴はほぼ見ることないのでキレイにするメリットよりそのための労力のほうが大きい。PR単位で追えればいいし。レビューのしやすさならPR小さくすることを頑張りたい。

[justgg]

ブコメ含めて、自転車置き場の議論ってやつじゃない？

[gengesa]

コミットを綺麗にしなくていいから squash を使う運用は実用的で好き

[nunulk]

squash は賛否両論あるねぇ

[omega314]

rebaseはいいけどsquashは嫌い。

[tonza_dopeness]

git初期でもあるまいし、リモートブランチ壊してまでrebaseしたい理由がわからない。見たい範囲のコミットの差分見ればいいだけ。

[t2y-1979]

あまり困ったことないけど、ワークフローはあった方がよいかな

[buzztaiki]

PRの中で世界が閉じてる方がmainlineの履歴は見やすいけど、squash運用はどうしてもconflictとの戦いになりがちなりがち。

[Nyoho]

“git config rerere.play true”

[kazkaz03]

“branch -dではfeatureブランチが消せません。強制的な削除のbranch -Dを使う必要があります。”マージコミット派なので知らなかった。ちょっと面倒だな。

[syu-m-5151]

とても良い考察。Version Control with Git, 3rd Edition の翻訳版である実用 Git 第3版もリリースされたし今年はちゃんとGitを勉強するにはいい年(実は毎年そう)。 https://www.oreilly.co.jp/books/9784814400614/