After reading this article, it makes sense to rebase to gather changes from the main branch on to my feature branch: Git workflow and rebase vs merge questions
c
If you are working alone the rebases do nothing. You did not commit anything new to master.
Your merge will be a fast forward merge and you could do it by not checking it out at all with
git push . HEAD:master
Whether you are working with someone or not, merging work that is in master into your feature branch is a bad practice. It is called a back-merge. The reason that it is bad is that you now do not have an atomic piece of work. the history of master is now entangled with your feature making working with this feature, such as rebasing, impossible in many situations.
You need to think about your branching strategy and what you want to achieve. Here is mine:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
You can see that each branch starts from the same place. You have a separate integration branch and release candidate branch to mix and match the features you want while not contaminating them.
As for collaborating on one feature with a colleague, it depends on how large a feature is (the granularity of your work). If it's large, you can apply the process above to the feature itself and branch per task instead.
If it's a small feature you can merge or rebase on that branch - it won't matter much. At this point it comes down to what the team is comfortable with.