こう
- 「merge と rebase の
違いを 説明してください」 - 「main の
変更を 自分の ブランチに 取り込むとき、 どちらを 使いますか」 - 「rebase してはいけないのは、
どんな ときですか」
面接官が
- 「どちらも取り込む操作」で
止まらず、 履歴の 形の 違いで 説明できるか - rebase が
コミットを 作り直す操作だと 分かっているか - 共有した
ブランチを 書き換えない、という チームの 決めを言えるか
短い答え
- merge は 2 つの
ブランチの 履歴を そのまま 残し、 合流の コミットを 1 つ足して まとめます。 - rebase は
自分の コミットを 相手の ブランチの 先に 付け替えて、 履歴を 一直線にします。 - rebase は
コミットを 作り直すので、 ほかの 人と 共有した ブランチでは 使わず、 手元だけの ブランチで 使います。
少し
同じ
main と feature が 1 つずつ別の--graph は
ターミナル
git init -q -b main demo
cd demo
git config user.name Aya
git config user.email a@x.jp
echo "base" > base.txt
git add base.txt
git commit -q -m "土台"
git switch -q -c feature
echo "a" > a.txt
git add a.txt
git commit -q -m "機能A"
git switch -q main
echo "b" > b.txt
git add b.txt
git commit -q -m "修正B"
git switch -q -c rebased feature
git rebase -q main
git log --graph --format=%s
git switch -q main
git merge -q --no-edit feature
git log --graph --format=%s* 機能A
* 修正B
* 土台
* Merge branch 'feature'
|\
| * 機能A
* | 修正B
|/
* 土台上の 3 行が rebase の
rebase は
rebase で
どちらを選ぶか
- merge は、
いつ分かれていつ合わせたかが 履歴に 残る。 共有した ブランチでも 安全に使える - rebase は、
履歴が 一直線で 読みやすい。 まだ 自分だけの ブランチを、 最新の main の 上に 乗せ直す ときに向く
チームに
作った
よく
- 「rebase の
ほうが 新しいので 上」と言う 優劣ではなく、 履歴の 残し方の 違いです。 場面と チームの 決めで選びます - 共有した
ブランチを rebase して、 強制で push する ほかの 人の 手元の 履歴と 食い 違い、 作業を 失わせる おそれがあります - 「rebase しても
コミットは 同じ」と言う 付け替えた コミットは 作り直された 別物です。 だから 共有した 所では 使いません
深掘りの問い
- 「fast-forward の merge とは
何ですか」 main 側に 新しい コミットが 無い とき、 合流の コミットを 作らず、 main の 名札を 先へ 進めるだけで 済む 取り込み方、と答えます - 「rebase の
途中で コンフリクトしたら」直して add し、 git rebase --continueで続ける、と 答えます。 やめるなら git rebase --abortで戻せます - 「git pull と git pull --rebase の違いは」取ってきた
変更を merge で 合わせるか、 rebase で 合わせるかの 違い、と答えます