Objective: Describe the difference between merge and rebase, and when to use each.

Let start with the problem we want to solve.

Problem: How to keep a branch in sync with the teams latest changes?

Different approaches are available, depending on the circumstances.

Merge

Merging is a non-destructive approach.
It will create a merge commit containing upstream changes and place it into your feature branch.
Scenario: Keeping a feature branch up to date with main

• You create a feature branch from main on May 1st.
• You work on your feature branch for a week.
• Commits from other team members are merged into main
• Your feature branch is now out of sync
• git merge on May 10th
  • Will bring in changes from main into your feature branch as a new commit (containing changes since May 1st)
  • All changes will show up in your history when a PR is raised to go back into main (even changes from main)

Pros:

• Linear history is maintained

Cons:

• Longer lived branches and/or active main branch makes for a messy history.
  • Your changes are mixed in with other's changes
• Identifying only your changes in the PR is much more difficult

When should I use git merge?

When others are actively sourcing this branch for work. e.g.

• main
• feature branches

Because there are multiple people relying on these branches, git needs to be able to reconstruct the history in a linear fashion; otherwise, git tries to fix it and ultimately the local copy of the branch is no longer in sync with remote (github.com). This, by design, will break git and what allows git to follow the distributed code versioning model.

Rebase

This alternative is a destructive option. It rewrites the history in a branch.

Pros:

• Cleaner project history
• Cleaner insight into PR changes
• Your changes are played after the latest changes from main

Cons:

• The changes happen only in your repository until you FORCE PUSH
• Feature branch will retain your changes as a BRAND NEW SET OF COMMITS

Scenario: Keeping a feature branch up to date with main

This can be interpreted as, “construct the changes on my branch to be placed after the changes on the main branch.”

This workflow applies to any branch serving as the source of truth, where child branches are dependent on newer changes from their parent branch.

• feature branch sourcing new changes from main
• story branch sourcing new change from feature branch

When should I use git rebase?

Rebase is great when you have complete control over branch and no one is actively dependent on it. You can rewrite history as much as you want. As a result, the local and remote branch can stay in sync with ease (with a force push git push -f). If you rewrite history on a branch, other people will not be able to pull it down without running into problems.

Conclusion

Git is a powerful framework for versioning code across teams and individuals. It doesn't force any certain workflow, in fact, it can be made to fit any common workflow in the software development lifecycle. Let me know how you use git to contribute to software in team-based settings!