Hi all, We have been using Git for about a year now in a very small team. So far, everyone has worked on their own local branches and been doing "git rebase master" to make sure their local branches stay in synch. This way we have a nice linear history in master. Recently, it has become useful to share one of these local branches between two devs. Of course, when one of the devs does his usual "git rebase master", he screws up the other dev's environment. Our solution has been to keep rebasing the shared branch but to actually work on a local branch that is rebased on the shared branch. By judiciously using "git reset" and "git pull" on the shared branch the two devs can keep the shared branch in synch and then use "git rebase shared-branch" on their local branch to keep it in synch to. While this works, there is probably a better/simpler solution. Should we simply do "git merge master" instead of "git rebase master"? And then do something at the end when we are about to merge the shared branch back into master to guarantee linear history? Your thoughts and ideas would be greatly appreciated. Cheers, Hilco -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html