I'm managing a git repo using the integrator work flow. In other words, I pull commits from my co-workers, and push them out to the blessed repo.
I'd like to keep the commit history linear for most cases, so is it OK to do a rebase instead of a merge when I integrate changes? Here is an example:
git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push
I'm concerned what will happen to the remote repos when they do their next git pull. Will git be able to handle this, or will the coworker repo fail during the pull, now that the commits are in a different order on the origin?
Update: I originally had the example rebase the 'coworker' branch from 'master'. What I intended was the opposite, to put the 'coworker' commits on top of the master. So I updated the example.
You definitely don't want to do what you suggest, it will rebase the master branch onto your coworker's master. Depending on what your coworker's master was based on you may end up often rewinding the central master.
What you might want to do is the opposite, rebase your coworker's master before merging it into master.
git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push
I still wouldn't recommend this, though. Your coworkers will have to resolve how you rebased their changes. Most of the time it's probably trivial and they can throw away their commits in favour of yours, but it's still something that they probably need to manually check.
Personally, I would recommend straight merging of their commits. If you feel that they are based on a too old version of master and the merge will be unnecessarily complex or based on an unjustifiably old commit then get them to rebase their master and refetch. Then at least they know what you are merging and they resolve any conflicts in their code.
Also, I would caution against aiming for unnecessarily linear history. Merging in developers' branches developed in parallel gives you a more true representation of history. If you rebase a developer's commit before merging then you no longer have a commit record that is an accurate representation of exactly the state of the code that that developer fixed and submitted. This may not matter very often but it may happen that two commits interact to produce a bug, but not a merge conflict. If you don't rebase, you get a more accurate (and fairer!) 'blame'.