Workflow question: A case for git-rebase?

Hello all,

So we've (as in my place of work) have switched from SVN to GIT although I do have a few questions -- hopefully they're not too obvious. :)

We have our master branch which is where all the latest changes are added to as a "remote shared repository which everyone pushes and pulls to. That's emulating pretty much what SVN did -- which is fine.

As for myself, I maintain _locally_ a few branches (branchX, branchY) which dictate some bits and pieces I'm working on. Periodically, I will tend to merge either merge to master and then push those changes out. So far so good...

But, I've now come up against a case whereby if one of my colleagues changes a file (call it fileA) in branch master, and, in the course of my working in branchX means i modify fileA also, when I come to merge branchX into master I find the original change in master (as submitted by my colleague) being reverted by my changes in branchX. Luckily I don't commit that since I do a git-diff beforehand. :)

One suggest solution to this is to merge master into branchX/branchY periodically, although this has the same problems as described when I try to merge -- if I'm going to make branchX the same as master, I might as well just work in master and be done with it, right?

So I was wondering if it's fine to branch from master at any given point and perhaps use git-rebasse when I come to merge? Is this even the correct mode of working? Indeed, there might be times when git-rebase isn't necessary if a merge to master from branchX or branchY won't revert a commit in master because that file had been edited, so how do I determine when to use git-rebase in this case? Or is that the correct indicator?

I do hope that makes sense.

Kindly,

Thomas Adam