Workflow question: A case for git-rebase?

["Thomas Adam" <thomas.adam22@gmail.com>]

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