Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> writes: > 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"? That certainly is a sensible thing to do. But if your people are used to rebasing their own 'master' on top of shared 'master', I would imagine that it wouldn't be hard at all for these two people that work on a topic branch to do the same for their 'topic' branch, no? Just like rebasing their 'master' on shared 'master', they would rebase their own 'topic' on shared 'topic'. -- 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