Re: Linear history *and* share a branch?

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 4/5/2012 3:48 PM, Hilco Wijbenga wrote:
> 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.
>
I haven't tried this, but at the point when your topic branch is ready 
for master and the only thing left to do is make the history linear 
before publishing it you could: rebuild the branch using cherry pick. 
You could cherry pick only the merge-commits over and that would drop 
all the merge history.  You would end up with linear history.  Then you 
could further cleanup that linear history with rebase -i before you 
publish it.

I haven't tried cherry picking a merge commit so I'm assuming it only 
brings over the commit content and not the merge history.

v/r,
neal