Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Don't be afraid to $git rebase

Don't be afraid to $git rebase

We, the front-end team, have decided to use git rebase and I saw this as a great opportunity to neatly summarize the aspects I hadn't tried to understand until now.

## Motivation to Use Rebase Instead of Merge
- Wanting to keep the commit history clean
- Some teams find git histories cluttered with merge commits, making the history less desirable to navigate.
- It's not about choosing one over the other; it's better to use them depending on the team or situation.
- Since knowing about them is crucial for proper use, this discussion will focus more on understanding how to use them rather than debating their pros and cons.

## Things to Know in Advance
- Fast-forward and no-fast-forward
- Fast-forward simply moves the main branch pointer to the latest commit.
- Non-fast-forward creates a merge commit.
- While there are pros and cons to both fast-forward and non-fast-forward, I'll skip discussing them today and focus on explaining how they work.
- Mechanism of rebase
- Rebase involves reattaching the changes in the feature branch onto the end of the parent branch (in this case, main), hence the term "re-base."

## Handling Different Cases
- Worries about conflicts while rebasing
- If it seems tiring to resolve conflicts one by one, it's okay to opt for a merge.
- FYI, if the conflict resolution results in no differences from the latest commit, there's no need to commit. You can conclude conflict resolution by executing `git rebase --skip`.
- Facing issues pulling changes from a rebased parent branch on GitHub to the local
- Resolve by using the `--rebase` option with the git pull command.
- Feeling anxious about "history rewriting" and the possibility of overwriting others' work by force-pushing changes
- It's recommended to use the rebase command only on branches that you alone are handling.
- Use `--force-with-lease --force-if-includes` for a safer force push.
- **[Making git push -f Safer with --force-if-includes - id:onk's Hatena Blog](https://onk.hatenablog.jp/entry/2022/12/18/000000)**

## References
▶︎ [Git Ain't Scary](https://www.slideshare.net/kotas/git-15276118)
▶︎ [Site Unreachable](https://youtu.be/7Mh259hfxJg)
▶︎ [Git rebase basics - YouTube](https://youtu.be/gkGZzd9c4ow)
▶︎ [Git rebase: how to resolve conflicts - YouTube](https://youtu.be/OXtdxHTh2oY)

Avatar for Yuki Shibata

Yuki Shibata

January 06, 2023
Tweet

More Decks by Yuki Shibata

Other Decks in Programming

Transcript

  1. feature main Merge Commit history will be messy and hard

    to read eventually because of the merge commits.
  2. Merge vs Rebase Pros Cons Merge - Intact and traceable

    commit history - Easier to understand the usage and how it works - Can be messed by a ton of merge commits Rebase - Flat commit history - Dangerous if you use rebase for the shared branch with other team member - Can be pain to resolve the conflicts