Gitコマンド入門::rebase(-i,drop,その3,#B)「第十九回」
みなさんこんにちは! 前回は途中終了で済みませんでした。ごめんなさい。この後の続きをどうするのか、ちょっと考えていましたので、途中終了が良いかな? って思った次第です。
そもそも、drop を使うシナリオも想定していないですし、やみくもにやっても、混乱を招くだけですからね。とはとは言っても、私も学習途中なので回り道は仕方ないと思いますいし、どちらかというと、多少の迂回しながらの試行錯誤する方が、後々、みなさんに役立ってもらえるかなと、そんな風にも思ったりしているんですよね~ まあ~ソフトウェア、システム開発って、その他、自己学習って、私にとっては、永遠に終わりがなく人生とおなじようなもの、また楽しいものだと感じています。どう進めるのか? どう理解しておけばよいのか? どんな疑問をもって、どんなアプローチで解決していくのか? たった、このgitコマンドにさえ興味を注がれます。というか、ソースをダウンロードして、ソースを見たい!(大爆笑)・・・まあ~このご時世、そんなことをしていたら、いくら時間があっても足りないので我慢して置きますけどね~ それでは、今日も前置きが長くなってしまいましたが、進めて行きましょう!
次回の記事はこちらから!
git本家本元の情報はこちらから!
まずは、rebase コマンド入力!
$ git rebase -i --root
vi エディターで編集
pick c0f998d 1st
drop 0fa830d A // <-- ここを、pick から、drop に変更!
pick f8b5ccd B
pick 2d138a2 C
pick cb468d1 D
// 以下~ 中略
viエディターの保存と終了は、Esc + wq
エラーの出ないマージの仕方!
Aを、Drop 指定すると、1stとBのマージになります。「ここ!」
ハッシュ値 | コメント | README.md | 補足事項 |
---|---|---|---|
c0f998d | 1st | # rebase | ここ! |
0fa830d | A | # A | drop削除 |
f8b5ccd | B | # B | ここ! |
2d138a2 | C | # C | - |
cb468d1 | D | # D | - |
vi を終了後のREAMD.md の状態
$ cat README.md
<<<<<<< HEAD
# rebase
=======
# B
>>>>>>> f8b5ccd... B
1stとBの自動マージ機能で、コンフィクトした箇所を確認しましょう!
dropするのに、いきなりマージを求められるのもなんですけどね・・・
viの編集で、Bの内容を採用してください。
# B
Bの内容そのままです。もしくは、'git restore --source=ハッシュ値 README.md` コマンドでも、OKです! ここでは、f8b5ccd ですね。
git restore --source=f8b5ccd README.md
add して、commit
$ git add README.md
$ git commit --amend
// viが起動して、コミットのメッセージの内容を求められるので、
// 1st + B と、私は入力しました!
log 確認!
git log --oneline --reverse
6c3db8d (HEAD) 1st + B
現状の確認、新しいハッシュ値 6c3db8dに変わり、HEADに設定されています。
status 確認!
$ git status
interactive rebase in progress; onto 3e7f827
Last commands done (3 commands done):
drop 0fa830d A
pick f8b5ccd B
(see more in file .git/rebase-merge/done)
Next commands to do (2 remaining commands):
pick 2d138a2 C
pick cb468d1 D
(use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'main' on '3e7f827'.
(use "git commit --amend" to amend the current commit)
(use "git rebase --continue" once you are satisfied with your changes)
nothing to commit, working tree clean
いろいろと案内が出ていますが、
git rebase --continue
を入力!
Successfully を表示されて無事完了!
$ git rebase --continue
Successfully rebased and updated refs/heads/main.
$ git log --oneline --reverse
6c3db8d 1st + B
cd0a8a8 C
e3f6029 (HEAD -> main) D
$ cat README.md
# D
ハッシュ値:旧 | ハッシュ値:新 | コメント | README.md | 補足説明 |
---|---|---|---|---|
c0f998d | 6c3db8d | 1st + B | # B | 1stとBのマージ処理結果 |
2d138a2 | cd0a8a8 | C | # C | - |
cb468d1 | e3f6029 | D | # D | - |
これで、上記の表の状態になり、ひとまず安心。ただし、Aをdropすると、1st+Bのマージになるので、2つも同時に減ることになりますので、シンプルに考えると、squash の方が安全ですね。そもそも、gitは、チェーン状のデーターベースですからね。途中をdropしたり、insertする時って、それなりの修正コストが発生するようです。
reflog で、HEADの履歴を確認!
$ git reflog
e3f6029 (HEAD -> main) HEAD@{0}: rebase -i (finish): returning to refs/heads/main
e3f6029 (HEAD -> main) HEAD@{1}: rebase -i (pick): D
cd0a8a8 HEAD@{2}: rebase -i (pick): C
6c3db8d HEAD@{3}: commit (amend): 1st + B
c0f998d HEAD@{4}: rebase -i: fast-forward
3e7f827 HEAD@{5}: rebase -i (start): checkout ```
予想したイメージ通り、3行目で、(pick): C、2行目で(pick): Dとなっていますね。今後も複雑な処理のときは、reflogで、直近のログ履歴を確認しながら進めると、宜しいかも?!
ここまでのまとめ!
- 今回、# Bと修正したら、コミットが2つ減り、1st + B, C, D の3つなった。
- 前回、# Dと修正したら、コミット数が、1st + D、の一つに集約された!?
それでは、今回はここまで、お疲れ様でした!
Discussion