コミット対象をよりわけるのをやめてみよう - 日々常々

git add {ファイル名} でステージングするファイル単位で選べます。10ファイル変更しててそのうち3ファイルだけコミットしたい時とかに便利です。 git add -p でステージングする変更を行の塊単位で選べます。関係ないコメントを足しちゃったのとか、うっかりついでに変えてしまった変更をコミットから避けたり、別のコミットにしたい時とかに便利です。 間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。 なので git add -A を基本にする。 ……とか言いつつ git add . を常用している私。単にタイプ数と手の慣れ。ちなみにgitのaliasは使わない派です。これは違う環境でコマンド叩く機会が多かったりする都合です。 理由 を並べてみます。 コミット対象を選択するのがいちいちブロッキングなので時間がかかる 10ファイルの変更から3ファイル選択する時間は g

[bouzuya]

git add -p → git commit したあとは、 git stash -u して（コミットだけの状態にして）コンパイルとテストを通したあと、 git stash pop してするようにしている。

[kotas]

これは確かになーと思った　“偽造するより素直に歴史おいとく方がいいよ。今よりわけられるなら未来でもよりわけられるよ。必要になった時でよくないかな”

[ledsun]

“混ざる状態で進めてたんですよね、としか……” わかるけど、難しい＞＜

[mt_hodaka]

細かくコミットしてあとからrebase -iで整える派。というかadd -pとかrebase -iはセルフレビューのキッカケになるってのが大きい気がする。セルフチェックしないでPR出すとしたらそれこそ時間泥棒だ

[iww]

エイプリルフールネタかと思ったけど違った

[kobito19]

"チームで合意がとれてるやり方でやるのが一番なんじゃなかろうか" こんなんチームで合意採るものじゃないでしょ。ちなみに自分は使う。

[s083027]

「〇〇修正」「typo修正」「typo修正」「レビュー指摘反映」「typo修正」

[peketamin]

慣れた人たちにとっては簡単でうまみもある習慣なんだろうか、と思うこともあるけどなかなか...履歴が整理されてて嬉しかった記憶があまりない。開発対象によって違うんだろうなぁ

[hachibeechan]

まぁ、どちらもメリデメあるしチームで合意がとれてるやり方でやるのが一番なんじゃなかろうか（大人力）

[bamch0h]

ここら辺の肌感、個人で趣味でやってると全然わからんのよな。全部 git add . だし git commit -m “Update” なんよ。なんなら作りきってから git init するし。

[katzchang]

すげーわかる、俺もこれ