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?
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.