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

https://www.atlassian.com/git/tutorials/setting-up-a-repository

...Skipping the basics

./index.js

export default () => {
  console.log('Hola')
}

> git add ./index.js

1
2
3

https://www.atlassian.com/git/tutorials/saving-changes

✅

./index.js

export default () => {
  console.log('Hola')
}

> git commit -m 'add hello'

1
2
3

https://www.atlassian.com/git/tutorials/saving-changes/git-commit

📼

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

`git merge`

Merge

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

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

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"

https://www.git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Setup-and-Config#_core_editor

ℹ️ 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

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 commit and optionally git 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

🐦 @paul_melero

Thanks for your help, Joshua Coady!