AR ホームベーカリー

オイラのアウトプット用ホームベーカリー！

git で rebase するときの手順

git

何回もやるのがなれるコツというか度胸がつく、という感じなのは場数を踏むっていう言葉通りなんだなって感じですネ。

rebase したいとき

ワイが master (main) から派生したブランチで開発中に、別の修正が取り込まれて master (main) 更新されとるやんけ！ という時にやる。 ここでマージ失敗してコンフリクト！ みたいなのがよくあるシナリオだけど、今回はコンフリクトは無いものとする。 (コンフリクトしたら地味に解消するしかないので)

あとは「マージする時は必ず rebase してからね」みたいな文化もあるんでしたっけ？ めちゃクソ大きい規模で開発したことないから、扱う感覚がよくわかんないんだよな……。

rebase する

(master (main) から) 派生したブランチで作業中だったので、マージ先も master (main) です。

  1. git stash (コミットしてないが反映したくない変更があればやっておく)
  2. git switch master
  3. git pull
  4. git switch ${開発してためったいいブランチ}
  5. git rebase master (ここでコンフリクトが起こったりするので、その場合はがんばって解消する)
  6. git push --force-with-lease origin ${開発してためったいいブランチ}
  7. git stash pop (stash 送りにした変更をローカルで戻しておく)

--force-with-lease がポイントで、ざっくりいうと「リモートとローカルの状態を比較して、最新に揃ってるっぽければ push したるわ！」という感じです。 -f (--force) だけだと意味合いが変わって強制的に反映されてしまうので、気をつけようね！

git-scm.com

rebase はコワクアリマセーン

自身がないなら、今の作業ディレクトリまるごとコピーしてどっかに退避しといて、 rebase してみればオッケーです。 push しなければ壊れるの自分のローカルだけなので。 壊れたら作業前バックアップとよくわかんない状態2つのディレクトリ用意してありやす！ ちゅって誰かわかりそうな人に相談すりゃええんよ。

どちらかというと、怖いのはコンフリクトとその解消デースってのが個人的感想です。