はじめに
rebase後にfeatureをmasterにマージする際に、fast-forwardをした場合と、コミットログを残す場合の違いをSourceTreeを使って確認します。
準備：ブランチをrebaseする
まずmasterからfeatureを分岐します。
交互に両方に何回かコミットします。
featureを選択し、masterにrebaseします。
> git checkout feature
> git rebase master
エディタで競合を解決してrebaseが完了するまで繰り返します。
> git add.
> git rebase --continue
rebaseができたらmasterをチェックアウトします。
> git checkout master
fast-forwardの場合
masterをチェックアウトした状態で、featureを右クリックしてマージ
> git merge feature
rebaseしたので何も指定しなければ通常はfast-forwardになります。featureはmasterを完全に含んだ状態なのでマージする必要がなく、HEADが移動するだけです。
同じブランチ上でコミットした場合と同じ状態です。どれがfeatureブランチでの作業かは分らなくなっています。修正範囲が小さい場合や凡ミスの修正はこちらのほうがすっきりして良さそうです。
コミットログを残す場合
masterをチェックアウトした状態で、featureを右クリックしてマージ。その際にno-ffオプションをチェック。
> git merge --no-ff feature
分岐が発生していたことがはっきりとわかります。機能ごとのコミットを把握したい場合は視覚的にわかりやすいです。細かい修正にまで多用すると、ごちゃごちゃしてわかりにくくある可能性はあります。mergeのコミットログとadd3は同じ状態なので無駄といえば無駄なログです。
まとめ
感覚的には分岐が残っていたほうがわかりやすいかなと思いますが、修正内容や運用によるかなと思います。コミットログがわかりにくい場合は明示的にコミットしたほうが良いかもしれないと思いました。その場合は、rebase -iやsquashでコミットログを整備する方法もあります。SourceTreeの価値はこの樹形図の見やすさにあると思いますのでうまく活用したいです。