diff options
| -rw-r--r-- | cheatsheet.txt | 43 |
1 files changed, 41 insertions, 2 deletions
diff --git a/cheatsheet.txt b/cheatsheet.txt index 3a66a5b..958c8cc 100644 --- a/cheatsheet.txt +++ b/cheatsheet.txt @@ -94,8 +94,47 @@ History Cleanup git merge master git rebase master - At this stage, run gitk and verify that you now have a linear history - that starts with master. + The last step ('git rebase') is where the rerere machinery mentioned + earlier may have to come to play and if you didn't have it enabled + during the development of, things may not go very smoothly and we + need this side note: in general, rebase is no magic, what it does is + take the patches from commits that you have and try to replay them + on top of your new base, resolving conflicts just like merge does. + + So, if during development of your feature branch you had a merge + conflicts that you had to manually resolve, then you will have + merge conflicts during rebase that you will have to resolve as + well. + + This is where rerere comes in. What it does is record your conflict + resolutions when you first manually resolved them during your feature + branch development. When later, during rebase, it sees that the same + conflict is being resolved during rebase, it automatically applies + the stored resolution. So if you didn't have rerere enabled from the + beginning, this should explain why things didn't go smoothly for you: + since you didn't have rerere enabled during your earlier merges, it + didn't record the resolutions. And in this case what you would have + gotten is a normal merge conflict, just like the first time, that + you have to resolve manually again. + + Running 'git stat' should give you the idea of what needs fixing. Once + you have edit the files, run 'git add' and then 'git rebase --continue'. + + Now, a note on rerere: again, it is kind of magic but not exactly. + Specifically, it doesn't hide this whole process from you. Instead, it + applies the conflict resolution that it has stored from earlier but + stops for you to confirm that all is good. So what normally happens + is that you still get the rebase merge conflict except that it applies + the resolution and there is a message in git rebase output to this + effect. Now you need to review it (e.g., with gitk), run 'git add' + to confirm it's good, and then run 'git rebase --continue'. And of + the side node. + + If you managed to get through all this, run gitk and verify that you + now have a linear history that starts with master. If things got + hairy along the way, you may want to verify that the end result, + content-wise, is exactly the same as what you have started with + by diff'ing with the backup you have made at the beginning. The second step is to clean up the commit history of our feature branch since it may have "dirty", work-in-progress commits. This may |