How to use git strategies

Git rebasing is a helpful tool that allows developers to integrate changes from one branch into another in a cleaner and more streamlined way than merging. One of the main advantages is that it can help keep the Git history more organized and easier to follow. By replaying the changes from the feature branch onto the main branch, Git can create a linear history that shows the progression of the code over time in a more straightforward manner.

For example, to rebase your current branch to “master,” you typically use the following command:

git rebase master

During the rebase process, Git considers two sets of commits: the “theirs” and “ours” commits. The “ours” commits are the changes made on the branch that the feature branch is being rebased onto, while the “theirs” commits are the changes made on the feature branch.

There are different strategies to apply:

git rebase -Xours master
git rebase -Xtheirs master

Using the “theirs” strategy during a rebase means that Git will keep the changes made in the current branch and discard any changes made in the branch we’re rebasing onto. In contrast, using the “ours” strategy means that Git will keep the changes made in the branch we’re rebasing onto and discard any changes made in the current branch.

When to use which?

Use -Xtheirs when you want your branch’s changes to win all conflicts:

• Rebasing a feature branch after master has diverged
• You’ve already reviewed your changes and trust them over master’s

# "I want my changes, master can deal with it"
git rebase -Xtheirs master

Use -Xours when master’s changes should take priority:

• Pulling in someone else’s fixes that override your work
• Resetting a branch to match master while keeping history

# "Master knows best"
git rebase -Xours master

Common pitfall

Note that ours/theirs are swapped between merge and rebase:

This trips up even experienced developers. During rebase, Git “replays” your commits onto the target — so from its perspective, the target branch is “ours” (what we’re building on) and your commits are “theirs” (what’s being applied).

See also

For more complex scenarios, check out:

• git rerere — remembers how you resolved conflicts
• git checkout --ours/--theirs <file> — per-file conflict resolution