Posted at

rebaseされたmasterをそのままmergeすると差分がでる

rebaseをほとんど使ったことがなく、なんでこうなるの??となったので調べてまとめました


問題になったこと

rebaseされたブランチがmasterに取り込まれており、それをpullしてきてマージをした

コンフリクトが起きたが、git statusで確認をすると下記のような状態で、rebaseされた分のファイルが全て差分として表示されていた

(もともとpublic/fuga.htmlなどの変更はしていないので、コンフリクトをしたpackage.jsonのみが表示されるという認識だった)

$ git merge master

(コンフリクトの発生)
$ git status
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

modified: .gitignore
modified: package-lock.json
modified: public/hoge.html
modified: public/fuga.html
new file: resources/hoge.js
new file: resources/fuga.js
new file: webpack.config.js

Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)

both modified: package.json

このままコンフリクトを解消してプッシュをすると、すでにmasterに取り込まれているはずのpublic/fuga.htmlなどの変更も新規で変更したようになってしまう


理由

rebaseされているため、履歴が書き換えられている

それによりファイルの変更箇所としては同じに見えるが、コミットのidが変わっているため新規の変更として認識されてしまう


対応

push前にこちらもrebaseを行う

git pull --rebase origin master 

これにより、現在のmasterのコミットログの後に、自分の変更分のコミットログを追記する順番に変更ができる


コンフリクトが起きた場合

エディタがコンフリクトが起きたファイルの修正をしてaddする、その後rebase continueを実行する

git add conflict.php

git rebase --continue

こちらを参考にさせてもらった

Git開発でmasterの内容を開発ブランチに反映させる方法

これをプッシュすれば良いが、ローカルのコミットログとリモートのコミットログに差分が出てしまうため-fオプションをつけなければいけない

git push -f origin hoge

fast-forwardマージから理解するgit rebase

これで問題なくrebaseができた


rebaseへの反対意見

調べてみるとメリットとしては、「ログが綺麗になる」という意見が多かったが、「履歴を書き換えるべきではない」などの反対意見もあった

なぜ git rebase をやめるべきか