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

./index.js

export default () => {
  console.log('Hola')
}
> git commit -m 'add hello'
1
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
  1. Type i
  1. Add commands to the commits you want to change
  1. Type ESC
  2. Type ":wq"

  3. 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

  1. git checkout master
  2. git pull
  3. git checkout -b <feature-branch>
  4. (make some changes: git add, git commit and optionally git push)
  5. git fetch
  6. git rebase origin/master
  7. (fix conflicts if needed)
  8. git push -f
  9. (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

By Paul Melero

Git rebase 101

What is Git Rebase and what are the benefits of following a simpler workflow than git-flow

  • 1,342