よくある3つの困ったシナリオ
Gitを使っていると、意図せずコミット履歴が複雑になってしまうことがあります。これから紹介するのは、多くの開発者が一度は経験するであろう代表的なシナリオです。
シナリオ1: 他のフィーチャーブランチから派生してしまった
本来は最新の main ブランチから切るべき自分の作業ブランチ (my-feature) を、うっかり同僚が開発中の dev-feature から派生させてしまったケース。このままでは、Pull Requestに無関係なコミットが含まれてしまいます。
問題の状況
|
1 2 3 4 5 6 |
* commit C (HEAD -> my-feature) * commit B * commit A (dev-feature) ←本当はここから派生したくなかった | * 最新のmain (main) |/ * ... |
シナリオ2: 一つのブランチに複数の変更が混在してしまった
一つのブランチ (work-branch) で作業中、コミットCとDが実は別の機能 (new-idea) であることに気づいたケース。この2つのコミットだけを、新しいブランチとしてきれいに分離したい状況です。
問題の状況
|
1 2 3 4 5 6 7 |
* commit E (HEAD -> work-branch) * commit D ┓ * commit C ┛ ←この2つだけを分離したい * commit B * commit A * 最新のmain (main) * ... |
シナリオ3: 古いブランチから新しい作業を始めてしまった
数ヶ月前に作ったまま放置していた old-feature ブランチ上で、新しい作業 (new-work) を始めてしまったケース。main ブランチはその間に大きく進んでおり、古い履歴の上に新しいコミットが乗ってしまっています。
問題の状況
|
1 2 3 4 5 6 7 8 |
* commit Y (HEAD -> new-work) * commit X | * かなり進んだ最新のmain (main) | | * ... | |/ | * commit B (old-feature) ←古い派生元 |/ * 昔のmain |
これらの悩みはすべて git rebase --onto で解決できます。