Git Rebase Leads to Duplicate Code Review?

Question

Let's say I branch off of development with a feature branch:

development: A--B
                 \
feature:          C

Meanwhile, another branch is merged into development, adding the commit D:

development: A--B--D
                 \
feature:          C

So on branch feature, I git rebase development:

development: A--B--D
                    \
feature:             C

But now when I create a pull request to merge feature back into development, commit D appears as if it were a new change. I understand in reality there are two D commits, the original and a copy on the feature branch. But now I'm reviewing changes (D) that I already reviewed in a previous PR into development. Am I using rebase correctly?

Answer 1

I understand in reality there are two D commits, the original and a copy on the feature branch.

Only if you've made a mistake during the rebase. If develop pointed at commit D when you ran the rebase, then the rebase command would only have recreated commit C on top of it.

The most likely explanation I can think of is that you've run git rebase twice, once rebasing C correctly onto D, and then again rebasing both C and D onto B.

A common mistake is to rebase onto your local branch develop without updating it from the remote branch first. Instead of git rebase develop, you probably want to run git pull --rebase origin develop , or git fetch origin; git rebase origin/develop so that you're bringing in all the changes from the remote branch.

Answer 2

Instead of doing a git rebase you might want to use git pull --rebase.

This will perform a fetch and pull the changes from the remote, so you can fix conflicts (if any).

You can refer to this question so you can see more details about it.

Answer 3

You never gave the specifics of where/how you are "reviewing" changes, but I will point out here that in your post-rebase branch, the C commit is actually a new commit:

development: A -- B -- D
                        \
feature:                 C'     (the ' indiciates this is a NEW commit)

As a result, the changes introduced by the D commit in the development branch could appear differently as they interact with your work from the C' commit.