In contrast to @richardolsson, I wouldn't recommend that they merge master into their topic branches, if by merge we mean
git merge master.
It is definitely a good idea for them to take updates that have happened on master and update their topic branches to reflect those changes, so as to avoid everything breaking terribly, but git provides a bit of a better tool for this particular use case,
Conceptually, they are very similar and the outcome in terms of the codebase is often identical, however using
rebase can make the history of the project much clearer to someone looking at the logs, and help keep from having a gigantic history graph to look through, even though those can look pretty sweet.
merge, git takes the status of the two (or more) branches being merged, attempts to piece them together appropriately, and makes a commit reflecting that a merge has happened, unless the HEAD of the target branch is a direct descendant of the branch being merged in, in which case it doesn't need to do any diff/patch stuff and just plays the commits on top of each other (git calls this fast-forwarding).
rebase, git (conceptually) takes the target branch, goes back to the last commit that it has in common with the branch it's being rebased on, makes the commits from that branch, and then makes the commits from the target branch. An example may be in order:
You have two branches,
master, with commits
topic, which was branched at
B and has the commits
F. If you are on
git merge master, you can end up with a commit history that will look like
A B E F G where
G is the commit made by merging. If you rebase, git first takes
topic and makes it's commit history the same as
master, and then makes the commits in
topic, so you get a commit history that looks like
A B C D E F.
One major advantage of doing this, other than the clarity in log history, is that as long as there haven't been changes in
master since you rebased,
git checkout master && git merge topic or similar will always be a fast-forward, since all of
master's history is contained in
topic. The big caveat here is to
not rebase branches that are meant to be publicly shared, because the SHA-1s of the commits have to be rewritten, which basically means a bunch of meaningless conflicts.
It took me a while for the benefit of this to take hold in my head. I've since found that (for me at least, and so far...), the "best" workflow is to:
- rebase topic branches
- merge tracking branches
git checkout topic
git rebase master
# fix any conflicts, run tests, etc
git checkout master
git merge topic
This gives a very clear history, and pretty much ensures that if breakage happens, it happens on the topic branch. It also makes some of the tools like
git bisect a bit easier to use when you need to use them.
Anyhow, hope you found this way-too-long answer useful.