発想としては近いですが、重要なのはGitは行ごとに履歴を管理するということです。
今回のmainの初期状態、これが「コミット1」です。
python
1Hello World! // コミット1の行1 2My name is A
featureブランチで変更しました。これをコミットヒューチャー1と呼ぶことにします。
python
1Good Morning, Hello World! // コミット1の行1を変更した 2My name is A
この後、コミット1から派生したfeatureの行1の変更をマージした時、「コミット1の行1」が変更されます。
python
1Good Morning, Hello World! // コミットヒューチャー1の行1 2My name is A
その後、devブランチの内容をマージしようとした場合、
python
1Hello World!!!!! // コミットデベ1の行1 2My name is A
devブランチは元のmainブランチの行1、つまり変更前の「コミット1の行1」から変更を行ったことになるので、当然「コミット1の行1」に変更をしようとします。
しかし「コミット1の行1」はfeatureをマージした時に既に変更され、現在のmainの行1は、「コミットヒューチャー1の行1」になっているはずですね。
ですので、コンフリクトが起きます。
python
1Good Morning, Hello World! // コミットヒューチャー1の行1 ← コミットデベ1の行1はコミット1に入れたいのにもう存在しない 2My name is A
このときmainブランチの心境は、
「ヒューチャーさんからもデベさんからも同じ行の変更が来ちゃった。ヒューチャーさんの方が早かったけど、デベさんはヒューチャーさんの作業内容を知ってるとは限らないよね?デベさんのコミットでヒューチャーさんの行1を上書きしてもいいのかわかんない」
です。
ですので、マージしようとした人間に、どっちが正しいか教えてくれとコンフリクトエラーを出します。
これが、featureが行1、devが行2を変更していた場合は、おそらくあなたの想像通りの動作になります。
同じ行でないので、mainの行1はfeatureを取り込み、
mainの行2はdevを取り込む形です。
python
1Good Morning, Hello World! // コミットヒューチャー1の行1 2My name is A!!!!!! // コミットデベ1の行2
これが、gitは行ごとに履歴を管理するということです。
0 コメント