![[PukiWiki]](https://www.masatom.in/pukiwiki/image/kinosite.png "[PukiWiki]"){kind=small}
|
マージとリベースの結果比較 で、 どっちでもイイかなと思ったマージとリベースを、さらにもう少し追加で比較しました。どうやら、並行開発時の他のブランチの更新の反映は、リベースがよさそうなことが分かってきました。 やったこと †devから派生した dev_#50, dev_#60があって並行で開発してて、dev_#60がさきにdevを書き換えたとします。dev_#50の開発者は、書き換えられたdevの更新分を取り込んだうえで、devへ自分の更新分をマージするわけですが、devの更新分をマージで取り込んだ場合とリベースで取り込んだ場合で、どうなるかって比較をしてみます。 今回は、もうすこし臨場感を出すため、マージする時に修正をコンフリクトするようにしてみました。 public class Calc{
public execute(int source){
return source ;
}
}
こんなソースに、 dev_#60で修正 public class Calc{
public execute(int source){
// 消費税対応1.05倍 #60 2016/12/26
return source * 1.05;
}
}
こんな修正や dev_#50で修正 public class Calc{
public execute(int source){
/* 消費税対応1.08倍 #50 2016/12/26 */
return source * 1.08;
}
}
こんな修正を入れてコンフリクトさせます。 繰り返しですが、dev_#60分はdevに取込済みで、それを踏まえてdev_#50の更新をdevへ取り込むケースを考えます。 マージ †ふつうにマージします。 $ git checkout dev_#50 $ git merge dev このとき、競合が起きますが、落ち着いて修正を行い、 $ git add Calc.java ←あ、これ修正しているソースです $ git commit -m 'merge commit' でマージ完了です。さらに、dev側にマージします $ git checkout dev $ git merge dev_#50 さて、このマージが完了したdevですが、 $ git checkout dev_#50 $ git merge dev ここのマージはすでにdev_#50で修正されたところに dev分(すなわちdev_#60の修正)をマージしています。 そしてそれがdevへマージされるので、devからみると#60の修正が先なのに、その順番が逆になってることが分かります。  リベース †そこでリベースです。 $ git checkout dev_#50 $ git rebase dev このとき競合がでてなんかごっちゃごちゃ言われます。落ち着いて修正を行い、 $ git add Calc.java $ git rebase --continue ってやってリベースのcontinueを選びます。これでリベース完了です。リベースの考えかたに従い、まずdev_#50のコミットが待避され、devの修正が取り込まれて、さらにdev_#50の新規コミットが行われます。 さらに、dev側にマージします $ git checkout dev $ git merge dev_#50 今回はマージでなくてリベースを行ったので、devに取り込んだもの(すなわちdev_#60の修正)が先で、そこにdev_#50の修正がマージされました。  まとめ †マージは、文字通りのマージで、devの修正をdev_#50の「いま」にマージしました。結果、devからしてみると「dev_#60の修正を先に取り込んだんすけど」という事になってしまいました。 リベースは文字通り、Re-baseすることでdev_#60を取り込んだところをベースに、dev_#50のコミットが行われ、それがマージされていきました。 この場合は、リベースをするのが正しそうですね。 関連リンク †
この記事は 現在のアクセス:2231 |
rebase.png
merge.png
