[レポート] 『きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会』に参加してきました | DevelopersIO

論理性の高い commit を作る方法 git rebase -i コマンドを活用する。 rebase -i を使用することで commit の 結合/分割/書き換え/順序入れ替え が可能。 以下では一番使うであろう結合(squash)について紹介します。 $ git log --oneline bfc2a57 (HEAD -> master) TOP画面の実装 e84e22e エラーメッセージのtypo修正 ba76419 エラーメッセージの追加 こんな感じの commit log があったとします。 よくありがちなケースだと思いますが typo修正だけのコミットなんてまとめてしまいたいですよね。 そこで git rebase -i の出番です。 $ git rebase -i HEAD~3 # HEAD は @ とも書ける、便利 $ git rebase -i @~3 上のコマンドでH

[umai_bow]

個人的には、プルリクでやったことが文章でまとめられていれば、個々のコミットはhogeでもいいと思っている。commit は綺麗にするより、やった作業を愚直に残していくことが大事だと思う。

[diveintounlimit]

PRがマージされたらそれ単位になるし、どういう経緯で今の実装になったかはPR見れば分かるし、あんまり途中のコミットメッセージの綺麗さを頑張ってもなって最近思ってる。

[vndn]

Subversionと違って汚いコミットができるのがgitの強みだと思っている。この記事の言いたいこともわかる。なんというかもう1段階欲しいなあ。ブランチとかプルリクとかが後から追いやすければいいのかな。

[tolkine9999h]

恥ずかしながらgit add -pとか使ったこと無かったです・・・いろいろ参考になる。

[mas-higa]

git add -p / git rebase -i / rebase した後の push が、どうやるときれいなのか分からん。

[kabacsharp]

めちゃめちゃ勉強になりましたーっ

[yarumato]

git add -p git rebase

[naglfar]

-p と -i はオトモダチ。これに慣れると git を GUI で使うって何をしているのだろうという気分にさえなる。

[sezemi]

耳が、耳が、、、いたい

[hmd703]

丁寧なまとめ

[inabajunmr]

プルリク見りゃいいじゃん派はすげえわかる　ただプルリクのレビューをするときにコミットログが綺麗だと嬉しいんだ　コミットログが綺麗だと嬉しいプルリクエストはでかすぎるかもしれない