質問: git勉強中の者です。今までは一人で開発していたため、常にmasterブランチにコミットする使い方をしていました。 ところが、今後、複数人でgitを使った開発を行うプロジェクトが始まりました。 実は他の人もgitはあまりわからず試行錯誤しながら運用しています。 現在は、機能追加や修正等の案件ごとにブランチを作り、各ユーザーがそのブランチを共有して開発。 案件ごとに、上長のOKが出たところでmasterへマージするという方法を取っています。 ところが、これだとmasterブランチに各ブランチ内でのコミットも反映されますよね? 例えばブランチAで「部品1追加」「部品2追加」「部品1修正」等のコミットがあった場合は、 ブランチAをmasterにマージすればこれらのコミット内容も反映されますよね。 しかしこの方法だと、「やっぱりこの機能は外したい」と言った時にどのコミットまで遡れば良いのか混乱してしまいます。 わかりやすく言うと、masterのログには「機能A追加」「修正No110反映」などと言った最終形態?の状態を反映するだけにして、 それぞれの案件内で行ったコミットログなどはmasterには反映させたくないのです。 このような場合はどのように運営していけば良いのでしょうか。
回答: こんにちは。 ブランチ上のコミットをマージする際に一つにまとめるのは`--squash`オプションを使うことで一発で実現できますが、質問者さんが本当に求めているものは、おそらく`--no-ff`オプションではないでしょうか。 `merge --no-ff`は、マージする際にFast-Forwardingを無効にし、常にマージコミットを作成するようにします。これを使用することで「`master`から`ブランチA`へ分岐した地点」「`ブランチA`を`master`にマージした地点」を常にコミットログに残すことが可能になります。 運用方針次第ではありますが、質問の通りに機能単位でコミットを一つにするというのは、`master`にマージするような段階で行うのはあんまりオススメできないです。`ブランチA`上で積み重ねたコミット履歴を捨てていることと同義だからです。gitの持つ「変更履歴」という大きなメリットを活かすことができなくなります。 逆に、コミットの内容がWIP段階である場合や、実験的なブランチを操作する段階ではコミットをまとめたほうが見栄えが良くなるため、そういう場面で`--squash`は役に立ちます。