Best practice git merging two branches with many changes

Question

We are currently developing a new feature for an open-source project and therefore checkedout the master, and did a lot of chnages over the past months ( > 400 commits). Now we want to merge it upstream/master to build a final version.

The question we are facing now is, what is the best way to do the merge with upstream master?

$ git fetch upstream

$ git merge upstream/master

or

$ git rebase upstream/master

or something diffrent like git pull?

The main target should be to have to changes things multiple times.

Answer 1

I wouldn't recommend git pull; fetch followed by either merge or rebase is generally safer as you can preview what will happen next by comparing master and origin/master.

The decision to use merge or rebase might not be yours to make. Does the upstream repository have contribution guidelines? If so, you should follow those.

If the upstream repository has no contribution guidelines then either a merge or a rebase may be appropriate.

But based on this

We are currently developing a new feature for an open-source project...

I understand that there are multiple people working on this feature, and thus multiple copies of your repository. In this case I would strongly recommend against using rebase. This would cause your commit hashes to change, and can cause lots of difficulty. As a general rule, don't rewrite shared history.

So you're left with merge, which is probably what I would use in this situation.