Gitでマージの利便性がよくわからない。リベースとかチェリーピックは便利だと思う


sampleディレクトリの中のsample.txtというファイルがあったとします。sampleディレクトリに移動してmasterブランチにてsample.txtにhello
masterと書いてaddしてcommitした後に、developブランチを作成しcheckoutします。developブランチではhello
developと書いてaddしてcommitして、masterブランチにチェックアウトしました。masterブランチにdevelopブランチの内容を取り込もうとしてgit
merge developとやって見ればコンフリクトしますよね。

これは、sample.txtというファイルの変更がmasterブランチとdevelopブランチ二つで行われているために、どっちをマージしていいかわからず起こる衝突ですよね。ていうことは、マージの使い所って、developブランチに移動して例えばsampleディレクトリの中にNewsample.txtというファイルを作成して、それをmasterに取り込むって使い方しかできないってことですよね。

仮にdevelopブランチの状態が master + (coomit) + (commit) +
(commit)だったとしてdevelopブランチの変更をmasterブランチにコンフリクトせずにマージを行いたければmasterブランチの状態がmaster
- (developのcoomit) - (developのcommit) - (developのcommit)という状態になければいけない。

developブランチで作業してる間にmasterブランチに変更が加えられてcommitされていた場合、その時点でmasterブランチの状態はmaster
-(developのcoomit) - (developのcommit) -
(developのcommit)ではなく、全く新しいmasterに生まれ変わってるので、masterブランチにいる時にdevelopブランチをマージしたらコンフリクトが起こるってことですよね。

あんまり、便利なコマンドではないなと思ったんですが、どう思われますか




マージすると競合が発生する、ではなく、競合する変更をマージしようとしているのです。本来なら手動で解決すべき競合を、ある程度自動で解決してくれるのがマージツールです。

現実的には、ソースコードを並行して作業すると言っても大抵は別ファイルや、同じファイルでも別の箇所を変更することになるので、これらは git merge
が自動的に処理してくれます。自動処理ができないような競合は手動で解決しますが、競合してる個所をマークしてくれているので楽です。それも大変そうなら相手の作業が終わるのを待ってから変更を加えればよいです。

というわけで、git merge は便利に使ってますね。

コミット単体の差分を適用する cherry-pick やそれを連続して行う rebase と、まとめてマージを試みる merge
では仕組みが異なるので、前者の方が楽という場合もあるのかもしれませんが...むしろ個別に適用することで個別に競合が発生しがちなので、merge
で最後にまとめて競合解決する方が楽な場面の方が多い印象です。

それよりも、merge コマンド（でfast-
forwardでないマージ）の場合はマージコミットが作成されるので、どこから派生した何をいつマージしたのかが記録として残るという利点があります。逆にマージコミットを作りたくない場合はrebaseしますし、特定のコミットだけを取り込みたい場合はcherry-
pickを使う。こういった使い分けが一般的かと思います。

ちなみに質問に書かれた sample.txt の例を手元で試してみましたが、merge でも cherry-pick でも競合を自動解決できないですね。

