Commit 71732d75 authored by French, Robert's avatar French, Robert
Browse files

Rebasing Slides

parent dbd876e2
<!-- $theme: gaia -->
<!-- *template: invert -->
# Rebasing
### Git It Together
##### Oak Ridge National Laboratory
---
<!-- page_number: true -->
## What is rebasing good for?
* Clean up your history before submitting merge requests
* Get a long-running branch caught up with master
---
### Cleaning up your commit history
* Sometimes we work in long-running branches
* You may hack and hack and hack on something before it is ready to show off
* Not all of the commits in your branch are worth looking at!
---
### Catching up with master
* Again, sometimes we have long-running branches
* We may need to incorporate new work from `master` to make our feature complete
* Suppose the database schema has changed, breaking assumptions that used to be valid
* Rebasing helps us "replay" our work on top of a newer commit, **as though we had been working from that newer commit all along**
---
<!-- *template: invert -->
## How does rebasing work?
---
### A new feature based on old work
```
C (master)
| E (new-feature)
| |
B D
| /
A
[original]
```
---
### Rebase that feature onto current work
by moving the "base" of a branch to a different commit
```
E' (new-feature)
|
D'
C (master) /
| E (new-feature) C (master)
| | ====> |
B D B
| / |
A A
[original] [rebase]
```
---
### Rebase + Squash
```
E' (new-feature)
|
D' E'' (new-feature)
C (master) / /
| E (new-feature) C (master) C (master)
| | ====> | ====> |
B D B B
| / | |
A A A
[original] [rebase] [squash]
```
Now all of our work is bundled in a single commit
---
### Rebase + Squash + Merge
```
E' (new-feature)
|
D' E'' (new-feature) E'' (master)
C (master) / / |
| E (new-feature) C (master) C (master) C
| | ====> | ====> | ====> |
B D B B B
| / | | |
A A A A
[original] [rebase] [squash] [merge]
```
Now we have successfully integrated our new feature into `master`.
---
<!-- *template: invert -->
## What is the difference between rebasing and merging?
---
### `git merge` **preserves** history
* All commits from both the source and destination branches end up in the destination branch
* Merge conflicts are handled by creating additional commits
* History can become convoluted and unhelpful
---
### `git rebase` **rewrites** history
* Conflicts are handled by amending commits
* Unwanted commits can be dropped from history
* Many commits can be squashed into one, leading to a more concise history
---
### Pedantic caveat
* `merge` and `rebase` are not competing products
* Difference is between
* Merging a bunch of commits from a long-running branch
* Rebasing first, then merging a single commit with the same content
---
<!-- *template: invert -->
## Demo 1: A small project
#### The Inspirational Quote Generator
---
<!-- *template: invert -->
## Demo 2: A large project
#### Spack: LLNL's Scientific Package Manager
---
## Pro Tip: Rebase & squash before merging
* Much easier to resolve conflicts (there is only 1 commit to deal with)
* Hides mistakes from your co-workers
* (Makes you look like a genius!)
* Most importantly -- keeps your history free of "bad commits" (those that don't pass unit tests)
* This makes `git bisect` *much* more likely to yield helpful debugging results
---
<!-- *template: invert -->
# Questions?
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment