Gitの運用について。masterブランチへをキレイに運用したい。

Question

git勉強中の者です。今までは一人で開発していたため、常にmasterブランチにコミットする使い方をしていました。
ところが、今後、複数人でgitを使った開発を行うプロジェクトが始まりました。

実は他の人もgitはあまりわからず試行錯誤しながら運用しています。
現在は、機能追加や修正等の案件ごとにブランチを作り、各ユーザーがそのブランチを共有して開発。
案件ごとに、上長のOKが出たところでmasterへマージするという方法を取っています。

ところが、これだとmasterブランチに各ブランチ内でのコミットも反映されますよね？
例えばブランチAで「部品1追加」「部品2追加」「部品1修正」等のコミットがあった場合は、
ブランチAをmasterにマージすればこれらのコミット内容も反映されますよね。

しかしこの方法だと、「やっぱりこの機能は外したい」と言った時にどのコミットまで遡れば良いのか混乱してしまいます。
わかりやすく言うと、masterのログには「機能A追加」「修正No110反映」などと言った最終形態？の状態を反映するだけにして、
それぞれの案件内で行ったコミットログなどはmasterには反映させたくないのです。

このような場合はどのように運営していけば良いのでしょうか。

Answer 1

こんにちは。

ブランチ上のコミットをマージする際に一つにまとめるのは--squashオプションを使うことで一発で実現できますが、質問者さんが本当に求めているものは、おそらく--no-ffオプションではないでしょうか。
merge --no-ffは、マージする際にFast-Forwardingを無効にし、常にマージコミットを作成するようにします。これを使用することで「masterからブランチAへ分岐した地点」「ブランチAをmasterにマージした地点」を常にコミットログに残すことが可能になります。

運用方針次第ではありますが、質問の通りに機能単位でコミットを一つにするというのは、masterにマージするような段階で行うのはあんまりオススメできないです。ブランチA上で積み重ねたコミット履歴を捨てていることと同義だからです。gitの持つ「変更履歴」という大きなメリットを活かすことができなくなります。
逆に、コミットの内容がWIP段階である場合や、実験的なブランチを操作する段階ではコミットをまとめたほうが見栄えが良くなるため、そういう場面で--squashは役に立ちます。

Comments

[shimayu]

早速のご回答ありがとうございます。教えていただいたオプションを調べてみたら何となくですが見えてきました。

>ブランチA上で積み重ねたコミット履歴を捨てていることと同義だからです。gitの持つ「変更履歴」という大きなメリットを活かすことができなくなります。

これが懸念していたところです。
あくまでもブランチA内で行った履歴は残しておいていつでも見れるようにする。
masterでは「ブランチAで機能を追加した」というログだけあればいいかなと思ったのです。

でもそうなると案件ごとにどんどんとブランチが残っていくということになりますよね。
ブランチが残るということは容量が圧迫される、ということにつながります。今更ながらに気づきました。

皆さんはmasterにマージした後は不要なブランチと言うのはどんどん削除していくものなのでしょうか。
もしブランチを削除していくのであれば、masterには全ての履歴が残ったほうが確かに良いかなと思います。

[tamoto]

なるほど。順を追って説明しますね。

まず、gitにはブランチという「実体」は存在しません。gitに存在するものは無数の「コミット」オブジェクトだけであり、コミットが連なった鎖の先端に名前を付けたものをブランチと呼びます。コミットオブジェクトの先頭を変数に格納するようなイメージです。ただの変数がデータサイズにほとんど影響しないことは分かると思います。

ブランチの削除を行うことは、単なるリポジトリの片付けに近いもので、行うかどうかは運用方針次第です。マージしたら即座に削除する運用もあれば、ずっと残し続ける運用もあり得ます。

gitは「変更履歴」を永久に残し続けることが目的の一つなので、あまりにもダーティな履歴を全ては残したくない、という場面以外では、コミット履歴を改ざんするのは好ましくないです。一般的な運用方針であれば、「ブランチA」の履歴はmasterに丸ごと残しておくのが正道だと思います。