Git - Merge vs rebase

Question

I have had a look at When do you use git rebase instead of git merge? .

But I'd like to be sure about which solution to choose in this case:

I want to implement a new feature on master so I branch it to a new Feature branch.
I do 10 commits on Feature while someone else does other commits on Master.

My question is if I want to keep my branch apart from Master for testing purposes, but I need to test it with the new Master commits integrated. So, should I merge Master into Feature (and not Feature into Master which would apply my modifications on master before my testing) or do a rebase?

Answer 1

Why not create a new branch to test the merged version? For example:

git checkout -b test-merged-feature master
git merge my-feature
[... do your testing ..]

There's no particularly reason to do a rebase here, but if you haven't already pushed your feature branch, that'd be fine as well. These questions are partly about how you would want your history to look - some people don't like seeing lots of merges; some prefer it as a way of keeping track of which commits contributed to a particular feature.

Answer 2

Unless you have already pushed your branch (and you know others have cloned your repo), I would still do a rebase, as I mentioned in my own answer of "git rebase vs git merge".

Test or not, I usually do a rebase each time I update my local repo (git fetch), in order to ensure the final merge (Feature to master) will be a fast-forward one.

So it isn't just about how your history look, but it is mainly about making sure what you are developing isn't based on an old version of master, and keep working against the latest evolutions done in master over time.