Paul Melero
Web Developer
Git rebase 101
Recap on Git "Snapshotting"
(or how Git
saves our changes)
I'm in a (local) repository
- I create a new "Feature branch" called: issue/hello
- I start creating files...
...Skipping the basics
./index.js
export default () => { console.log('Hola') }
> git add ./index.js
1
2
3
2
3
✅
./index.js
export default () => { console.log('Hola') }
> git commit -m 'add hello'
1
2
3
2
3
📼
./index.js
(git push)
./index.js
(git push --set-upstream origin issue/hello)
We created a new "history point" in the linear history of changes.
COMMITS!
Working on Feature branches
We want to put our work in top of somebody else's
We want to put our work in top of somebody else's
git merge
Merge
PROS
- it’s a non-destructive operation
- Everybody knows git-flow
CONS
- Creates a new "merge commit"
- Could lead to unclear Git history (non-linear) and (weird branch "bubbles")
git rebase
Rebasing is the process of moving (or combining) a sequence of commits to a new base commit.
Rebase
PROS
- much cleaner project history (no merge commits)
- perfectly linear project history
- It comes with an interactive mode that adds powerful new tools
CONS
- It re-writes the commit history (in the branch applied)
- You need to feel comfortable using `-f`.
git rebase --interactive
p, pick <commit> = use commit r, reword <commit> = use commit, but edit the commit message e, edit <commit> = use commit, but stop for amending s, squash <commit> = use commit, but meld into previous commit f, fixup <commit> = like "squash", but discard this commit's log message x, exec <command> = run command (the rest of the line) using shell b, break = stop here (continue rebase later with 'git rebase --continue') d, drop <commit> = remove commit l, label <label> = label current HEAD with a name t, reset <label> = reset HEAD to a label m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] create a merge commit using the original merge commit's message (or the oneline, if no original merge commit was specified). Use -c <commit> to reword the commit message.
Commands
#1
#2
#3
git log
> git fetch > git rebase -i origin/master
> git fetch > git rebase -i origin/master
vim
How to change default's Git editor:
> git config --global core.editor <editor_name>
> git config --global core.editor "code --wait"
#1
#2
#3
ℹ️ Bare in mind the order of the commits is the opposite as the command
git log
- Type i
- Add commands to the commits you want to change
- Type ESC
-
Type ":wq"
-
Type Enter
#1
#2
#3
vim Workflow
Making changes to a commit message
Now your local history diverges from the remote one!
git push origin --force
git push -f
Create a Pull Request
Let's walk through the whole workflow again
-
git checkout master
-
git pull
-
git checkout -b <feature-branch>
-
(make some changes:
git add,git commitand optionallygit push) -
git fetch
-
git rebase origin/master
- (fix conflicts if needed)
-
git push -f
- (Create a Pull Request as usual)
❗
The Golden Rule of Rebasing
Never use it on public branches (main, master, dev...), only your feature branches.
☝🏽
Bonus Point: Solving Conflicts while rebasing
Contrary to a regular merge conflict, in a rebase the order is reversed.
But VS Code "gets it wrong" and the "incomming" is actually our changes in the branch we're in!
-
git rebase --continue
-
git rebase --abort
> git add ./index.js
- And then, either:
> git push
- Now, you can create the PR
Profit! 👏🏽
Do you wanna see how it looks like in the wild?
> git end
> git thank-you
Thanks for your help, Joshua Coady!
Git rebase 101
Git rebase 101
By Paul Melero
Git rebase 101
What is Git Rebase and what are the benefits of following a simpler workflow than git-flow
- 1,410
