-
1. check which branch you're on:
-
-
2. this shouldn't be necessary, but just in case, let's pull the latest changes of your own branch:
-
```shell
# while inside the same (your own) branch:
git pull
```
-
if you see something unexpected, there's probably changes from someone else, thus you answer "no" to [1.2](((PBP6PdUmS))), thus abort (unless ofc you know what you're doing).
-
-
-
3. since we want to rebase on top of the latest changes of master, we need to update our local git repo first:
-
-
4. if all goes well, we can start the procedure
-
```shell
git rebase origin/master -i
```
-
`-i`, or `--interactive`, will bring up the list of commits of your branch. you can view it to confirm everything's alright, and if not, you can squash/fixup/drop, even re-order the commits. basically, become a surgeon for a bit.
-
-
-
5. ideally, there are no conflicts, the rebase completes successfully and you can move on to the [next step](((q8jggl2cV))).
-
but if often does not.
-
you can always use `git status` to see what's going on
-
in case you encounter conflicts:
-
you need to manually resolve them, and then mark them as fixed with `git add <filename>`
-
if you forgot which changes are yours, you can always find the commit by doing `git log <branch-name-you-are-rebasing>`, finding the commit, and then doing `git show <commit>`.
-
when all conflicts are fixed and added, you can continue the rebase with `git rebase --continue`
-
there are some edge cases as well
-
e.g. if you resolved conflicts and your commit ends up being empty, you'll need to manually commit it with `git commit --allow-empty` and then `git rebase --continue` again
-
in general, git will tell you about it - you just gotta be careful and read thoroughly. ofc, also search for info / ask for help when needed.
-
-
-
6. git should print "successfully finished rebase" or something similar.
-
if you check `git status`, it'll show that you have more commits ahead and less commits behind. makes sense, since you previously had only your commits that you started from an older commit of the master branch, but you now have all of that, plus the new commits from the master branch that you were missing.
-
-
-
7. you'll now need to push the new history of commits to the repo (currently it's only local).
-
-
8. done. check the repo & verify everything looks good.
-
-
9. something went wrong? yay, learning time!
-
`git reflog` is your friend:
-
glhf. if you're a newbie w/ this stuff, consider copying the `.git/` folder outside the repo `../` in case you need to start from scratch.
-
talking w/ an experienced colleague / friend also helps.
-
-
10. good to remember:
-
rebase goes commit-by-commit (1 by 1)
-
it's easy to mess things up.
-
it's always better to do simple changes in multiple rebases, than multiple complex changes in a single rebase.
-
e.g., first you can get your changes up to date to the latest origin's master branch, and then in the 2nd rebase you can squash some commits into one parent commit, then squash some more commits into a different parent commit in a 3rd rebase, etc etc.
-
this often times helps avoid complex situations, and also helps avoid loss of partial progress - e.g. if you're rebasing and you've completed say 15 commits out of 20, but then you're on the 16th one and you f something up pretty bad, you'd have to abort. but with the abort you'll lose all of the progress and you'll have to re-do the same stuff for the 15 commits again.
-
so yeah, multiple simple rebases are better than fewer more complicated ones.
-
-