Re: Linear history *and* share a branch?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 5, 2012, 21:06 UTC
- Message-ID
- <7vfwch51nn.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com>
Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
Show 18 quoted lines
> 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'.