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

Question

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ブランチをマージしたらコンフリクトが起こるってことですよね。

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

Answer 1

git mergeで必ずしもコンフリクトするわけではありません。

git mergeが便利なのは、例えば、バグが見つかって、それを改修するためにbugfixブランチを切って、作業して、masterに取り込むといった際に使います。

merge機能がなければ、masterだけで作業しなくてはならなくなります。仮にmasterブランチだけで作業することになれば、ソース改変によってプログラムが動かなくなってしまったら、原因を突き詰めなければなりません。

しかし、bugfixブランチで作業していれば、仮に間違ったコードが混じっても、bugfixブランチを削除することだけで事足ります。

つまり、ある特定の状態をmasterとして担保したいがためにmerge機能があると思います。そういった理由からgit開発するのであれば、masterだけで作業するのは意味がありません。

Comments

[Chironian]

それって、マージではなくブランチのメリットでは？

[imamoto_browser]

正確にはブランチとマージのメリットってかんじですかね。Chironianさんが書いてある通り、masterで変更があった場合に手でマージするのは大変だからマージ機能が必要という説明が、マージがなぜ必要かという質問に対しては正だと思います。

そもそもブランチという概念がなければ、マージもできないわけですから、あくまで補足と捉えてください。

Answer 2

こんにちは。

複数の人が複数のファイルをメンテナンスしている状況を想像して下さい。
結構よくあることですね。
Aさんがファイルaの100-200行目を修正し、Bさんが同じファイルaの500-510行目を修正した場合、修正がこれだけなら、マージでコンフリクトしません。

このような修正をAさんとBさんがそれぞれ独立に多数のファイルに対して行っていた場合、両方の変更点を「マージ」する手作業は地獄ですし、そもそも間違いの元です。

確かにコンフリクトした場合だけは自動化できませんが、そうでない限り自動でマージしてくれるって本当に幸せなことだと思います。

Answer 3

まずはコンフリクトについて、例えばsample.txtを二つのブランチでそれぞれ変更したとしてもコンフリクトが起こるとは限りません。行単位にコンフリクトがチェックされるからです。この点は問題の本質ではありませんが実運用上知っておくべき点です。（実際のところコンフリクトは多くないという話でもあります。）

次に、コンフリクトは問題ではありません。

例えばsample.txtの内容が順不同のリストだったとして、
masterブランチが

A
B
C
D

で、developブランチが

A
D
B
C

だったとすると、マージした結果は

A
D
B
C
D

となります。また、この時コンフリクトは発生しません。
しかし、Dが２件登録されているのは無駄であり、メンテナンス時に漏らす可能性があります。

このようにマージの際には意味上のコンフリクトが起こっていないかのチェックが大事となります。

それと、masterブランチにすでにコミットされている内容はおそらく必要だからコミットされているわけで、developブランチをmasterブランチに取り込む際にはmasterブランチのコミットも取り込む必要があります。

つまり、マージそのものが問題であり本質的であるために、自動化が難しい点でもあります。（ユニットテストなどが助けてくれます。）

私はMercurialに慣れているのでgitの作法に詳しくないのですが、たしか、こういう場合、developブランチをリベースして、最新のmasterからdevelopブランチを切ったことにして、マージをするのが一般的な作法だったと思います。（詳しい人支援お願いします。）