git rebase は危険だ！悪だ！と言うガセネタに踊らされて rebase を怖がらないで！！！

rebase を恐れるなっ

rebase は危険だっ！push されてる場合は rebase するな！リポジトリを破壊するぞっ！絶対使うなっ！！

こんな脅し文句に踊らされ、人々は rebase に恐れおののき全力で逃げ出し理解すらしようとしなくなった結果、今日もログが荒れています。

私は悲しいです。

rebase は全く恐れなくて良いんです！むしろこんないい娘いません！！

本来一番自然な流れを作り出せるものですので、ぜひ理解して活用しましょう。

ってなわけで、訳の分からない変な呪縛から解き放つ、その手助けを今からいたします。

rebase は1つのブランチならば多人数でいじっている場合でも全く問題無いと言うか、merge の方が圧倒的に具合が悪いです。

rebase 実験

実験するとわかりやすいですからやってみましょう。

が、その前に以下を実行してください。

git config --global mergetool.keepBackup false

orig だの BACKUP だの作るのをヤメさせます。
(そもそも論 --abort だの reset だのがあるんだからこんなもんの必要性が全く無く鬱陶しいだけですし clean -f を毎回叩くのウザすぎです)

本サイトでは mergetool には vimdiff を使う事を強く推奨すると言うか、vim 使いましょう。それ以外認めません。

なので以下の設定を推奨です。

git config --global merge.tool vimdiff

[TODO]
rebase、marge でのコンフリクト解決の方法、vimdiff の使い方を機嫌が良い時に丁寧に教える記事を載せる。

その上で以下を実行してみてください。

mkdir -p ~/git-test/remote/test
cd ~/git-test/remote/test
git init --bare

cd ~/git-test
git clone ~/git-test/remote/test a
git clone ~/git-test/remote/test b

echo 'base code' > a/code
cd a
git add code
git commit -m 'first commit'
git push
cd ../b
git pull
cd ..

cd a
echo 'bug fix by a' >> code
git add code
git commit -m 'bug fix by a'
git push
cd ..

cd b
echo 'bug fix by b' >> code
git add code
git commit -m 'bug fix by b'

git push // Error

git pull -r
git mergetool
git rebase --con
git push

o [master] {origin/master} bug fix by b
o bug fix by a
I first commit

merge 実験

さぁ、今度は馬鹿みたいに merge してみましょうか。git の呪いを堪能です。

~/git-test 以下を全部消して実験コード[ Core ] と [ Bug fix by b ] を実行してください。

その後 b で以下を実行して merge します。

git pull
git mergetool
git merge --con
git push

ちなみに pull の際、エラーが出る場合は、

git config --global pull.rebase false

を実行してください。pull のデフォルト挙動が merge になります。以前までこんな設定せずともエラーにならなかったんですが、余計なお世話が入りました。

marge した結果のログが以下です。

M─┐ [master] {origin/master} Merge branch 'master' of /home/xxx/git-test/remote/test
│ o bug fix by a
o │ bug fix by b
I─┘ first commit

さっきは 3 行だったのが 4 行に増え、左側の部分も見づらくなりましたね。
さらに、時系列的に bug fix by a が先なのに、後に見えるようになり混乱出来ます。非常にありがたいですね。
まさにハッピーハッピーハーーッピーーーパピハピハピハピハーーッピーーーです。

まぁ、こりゃ remote の commit が先行したもんだから、そいつを自分ところの一番ケツにペシッとくっつけて、さらに merge で取り込みましたよ！とありがた迷惑な commit を作ってくれるからこうなるんです。

これ、remote 側に、まだ local に取り込んでいない commit が存在する際に push しようとすると、毎度こうなります。

これでログが最高に汚くなってログを開くたび絶頂を迎えることになります。

マジ最高！！ありがとうリーナス！！

rebase 一択

merge はあまりに最高すぎて絶頂を迎えすぎるため基本的に rebase 一択です。

なので

git config --global pull.rebase true

しても良いです。すると

git pull

が

git pull -r 

とおなじになるので。この場合 merge したいとすると

git pull --no-rebase

とオプションが長くなりますが、まぁ merge する機会の方が少ないので良いかと思います。

が、自分はもう手癖で git pull -r とやっちゃうし、普段は tig でやってるんでこの設定はしてないです(照)。

merge の混乱

ちなみに remote 側が一切触られていない merge は rebase と同じ結果になります。

それが ff です。フレンドリーファイアーでありファイナルファンタジーであり、forfeit であり surrender で gg です。ま、ff とかこんな言葉くっそどうでも良いので気にしないでください。

つか merge の挙動が remote の様子で変わるのがどうだっつぅ話ですわ。これが混乱の元。激キモオヤジの嫌がらせです。

rebase 使えと言っても、他のブランチに対してコードの統合を行う場合は rebase -> merge と言う流れになるのでちょっと混乱するかもしれません。これは私のせいではありません。git の出来が悪いだけです。

rebase で統合先の最新コードを引っ張ってきといて、それをそのまま統合先に merge で追加って感じです。

簡単に、この悪質な merge の挙動をまとめると以下のようになります。

他ブランチ取込 rebase 時の push --force に注意

話を戻して rebase が全く問題ないか？と言うと問題が発生する場合があります。

それは 他ブランチを取り込む場合、かつ自分が rebase の作業中に誰かがブランチに push した場合です。この push を消す可能性があるんです。

分かりづらいですかね。現実的なシチュで説明します。

master から新機能開発のために dev ブランチを切りましたと。

a が dev で新しい機能を追加しました。それを master に merge するために dev に対して現在の master で rebase します。

そら dev の元となった master に変更があったらそれを取り込むのは当たり前ですよね？

master の最新を取り込んだ dev を master に突っ込みます。終わり。

普通は特に問題は発生しません。

ただ、問題が発生するのが、rebase した後に、ブランチに対して変更をいれたやつがいる場合です。

もしその変更が push されていた場合、その commit が消えます。しかもおそらく気づかない。そっと消えるのでｗ。

まぁ消えたっつっても reset 使えば戻せるは戻せるから noob が騒ぎ散らすだけですがね。

んで、これは rebase が悪いのではなく、rebase 後の作業ブランチを強制的に push する

git push -f

がアブねぇって話です。(オプション長くて見るだけで憂鬱になる --force-with-lease を使えば安全って話でもないですよ)

回避策ともども説明しましょう。

他ブランチ取込 rebase 実験

さぁさっそく実験です。まずは、問題無い rebase です。以下を実行してください。

mkdir -p ~/git-test/remote/test
cd ~/git-test/remote/test
git init --bare

cd ~/git-test
git clone ~/git-test/remote/test a
git clone ~/git-test/remote/test b

echo 'base code' > a/code
cd a
git add code
git commit -m 'first commit'
git push
cd ../b
git pull
cd ..

cd a
git checkout -b dev
echo 'new func by a' >> code
git add code
git commit -m 'new func by a'
git push origin dev
git branch -u origin/dev

cd ../b
echo 'bug fix by b' >> code
git add code
git commit -m 'bug fix by b'
git push
cd ..

cd a
git pull -r origin master
git mergetool
git rebase --con

git checkout master
git pull
git merge dev
git push

o [master] {origin/master} new func by a
o bug fix by b
I first commit

他ブランチ取込 rebase & push 実験

[ Core 2 ] 実行して以下を実行してください。

cd a
git pull -r origin master
git mergetool
git rebase --con
git push // Error

push で死にます。今の master の修正を取り込んだものが remote の dev と衝突してしまっているのでエラーになります。

なんだ、だったら rebase すりゃ良いじゃん？っつって rebase してみるとこんな風になります。

o [dev] new func by a
o bug fix by b
o {origin/dev} new func by a
I [master] first commit

あれ、同じ commit 増えました・・・しかも bug fix と new func が入れ替わりました。そらそうですね。dev で rebase しちゃいましたから。こりゃダメです。

じゃぁ merge してみましょうか。

M─┐ [dev] Merge branch 'dev' of /home/xxx/git-test/remote/test into dev
│ o {origin/dev} new func by a
o │ new func by a
o │ {origin/master} bug fix by b
I─┘ [master] first commit

終わってます。

他ブランチ取込 rebase & push --force で人に迷惑をかける実験

素直なままの君でいて欲しい。ってなわけで、remote 側を local で問答無用で書き換えるのが

git push -f

です。-f は --force です。フォースの力をうんちゃらかんちゃらでブォーンブォーンです。

よっしゃー！これで解決やでぇ！！

とはならず、さっき書いたように、commit ぶち消し問題が発生する可能性があります。

[ Core 2 ] を実行後に、以下を実行してみましょう。

cd a
git pull -r origin master
git mergetool
git rebase --con

cd ../b
git pull
git checkout dev
echo 'new func by b' >> code
git add code
git commit -m 'new func by b'
git push
cd ..

a が dev に master を rebase 後に b が dev に対して変更を追加しています。

この時、a のログは以下。

o [dev] new func by a
o {origin/master} bug fix by b
I [master] first commit

dev が push されていないので、{origin/dev} がいません。

b のログは以下のようになっています。

o [dev] {origin/dev} new func by b
o new func by a
I first commit

new func by b が追加されていますね。

さぁ、a で force な push をしてみましょう。

cd a
git push -f	
cd ..

b で pull してログを見てみてください。

o [dev] {origin/dev} new func by a
o [master] {origin/master} bug fix by b
I first commit

「はぁぁぁ！？吾輩の new func by b が消えたっ！！」と発狂ですね。

困った事にこんな感じで何も出ずツルっと消えるんですよね。なので消えた事に気づかない可能性がある。こりゃいかんです。

周りに迷惑をかけず 他ブランチ取込 rebase & push --force & merge するには？

push -f で --force-with-lease 使うと、remote 側に変更があった場合エラーになるので、rebase やりなおしって話なんですが、conflict 解決中に push されると無限ループの始まりです。

なので、チャットで

「おい！ぽまいら！dev を rebase するンゴ！手持ちの commit を全部 push すれ！」

と古の激キモ言語で大号令をかけ、全部 push してもろて、

「rebase するから、push すんなし！」

と push を封じれば良いです。つか、それしかないです。

ちゃんと b に push してもらった後、改めて rebase すると以下のようになります。

o [dev] {origin/dev} new func by b
o new func by a
o {origin/master} bug fix by b
I [master] first commit

んで、この dev を master に merge するわけですが、この時 --squash を付けましょう。master のログに開発のログがぐちゃぐちゃ入るのマジ勘弁なんで。

git checkout dev
git pull -r
git merge dev --squash
git commit

これで

o [master] {origin/master} Add new func !!
o bug fix by b
I first commit

こうなります。はい、きれい。

rebase は ユーザーが変わるとか、hash が変わるとかありますが、そんなもん普通どうでも良いので気にしないくて良いです。

どう考えてもログが汚くなる方が致命傷だし変わる前を追おうと思えばなんぼでも追えますし。

push --force で自分の commit が消されてしまった場合の対応例

最後に、もし push -f で消えてしまった場合の復活方法の一例を書いておきます。

new func by b を消された b は

o [dev] {origin/dev} new func by b
o new func by a
I first commit

だったのが、rebase すると

o [dev] {origin/dev} new func by a
o [master] {origin/master} bug fix by b
I first commit

と、自分の commit が消えちゃいます。が、焦らなくても OK です。

git reflog 

で、作業リポジトリの履歴を表示します。

aaa75d9 (HEAD -> dev, origin/dev) HEAD@{0}: rebase (finish): returning to refs/heads/dev
aaa75d9 (HEAD -> dev, origin/dev) HEAD@{1}: rebase (start): checkout refs/remotes/origin/dev
fb23a21 HEAD@{2}: commit: new func by b
8137020 HEAD@{3}: checkout: moving from master to dev
c9a59bd (origin/master, master) HEAD@{4}: commit: bug fix by b
71e6fc7 HEAD@{5}: initial pull

以下が、消えちゃった修正です。

fb23a21 HEAD@{2}: commit: new func by b

なので、hard reset を使って、ここまで完全に戻します。

git reset --hard fb23a21

ほいだら以下です。

git reset @^
git stash
git rebase
git pop
git commit

reset で履歴を１つ戻して commit を取り消し、修正したコードを stash に突っ込んで rebase して stash から戻して commit しなおしって感じです。

では良い git ライフを。