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