How should we use git branches cleanly and effectively?

Question

We have a branch staging which is our master branch. This is the branch that gets deployed.

We have two developers. We want to work on features in isolation, but ensure compatibility before we push changes to staging.

How are we supposed to do this?

Here's what I thought we could do.

• I branch off from staging to create feature-avatar-edit.
• My coworker branches off from the same commit of staging to create fix-profile-alignment. He commits some stuff and finishes this branch, and merges it back into staging. He deletes fix-profile-alignment.
• I want to continue working on feature-avatar-edit, but I want my coworker's changes to exist in feature-avatar-edit, else I may create issues later when I finish and merge into staging. (Basically, when I'm almost done working on feature-avatar-edit, I want to confirm that it works perfectly, including with the changes from fix-profile-alignment that have been added to staging.)
• I switch to staging and do git pull to get the recent changes my coworker committed. I then do a git rebase to basically "move" the point at which feature-avatar-edit diverged from staging.
• I review the current state of feature-avatar-edit, make any fixes necessitated by my coworker's commits showing up in my branch, and merge into staging. I delete feature-avatar-edit.

What I've found so far is that rebase tends to introduce duplicate commits. What I expect to happen is this. Before rebase:

A    staging
| \
B |  merge fix-profile-alignment into staging
  C  feature-avatar-edit

After rebase:

A    staging
|
B    merge fix-profile-alignment into staging
  \  
  |
  C  feature-avatar-edit

1. How can I achieve the above without creating duplicate commits in our history? Or would working like this be okay?
2. How does the use of pull requests enter into it? Is it okay to do git rebase after a pull request has been created, assuming only one person works on that branch at a time?

Answer 1

I think your "duplicate" commits might be there because you have pushed to a remote (if not, we need you to show an example of history with duplicate commits).

Starting from:

--A---B---C - staging
       \---D - feature - remote/feature

After git checkout feature && git rebase staging:

           /---D' - feature
--A---B---C - staging
       \---D - remote/feature

You get a new commit D', but D is still there.

If that is your case, and if you can get away with destroying D altogether on your remote (no one else is using it or would get mad at you), you can update the branch on your remote with git checkout feature && git push <remote> feature -f.

Answer 2

This is exactly the way it is supposed to be done if you want a linear history.

There are duplicate commits because the content of the files from the rebased commits is different (since it contains changes from fix-profile-alignment), hence the SHA hash is different.

You can delete them from your history by deleting the commit object

As for the rebase, you are still on feature-avatar-edit after it, and stagging has not been modified. If you merge into stagging, then you should immediatly push stagging to the remote to avoid latter conflicts (otherwise you would have to do git pull --rebase to keep the history linear). But you can also do regular rebase to be sure your feature integrates correctly with the others (for example if the other developpers is developping a lot of small features and pushes regularly to stagging).