Re: Linear history *and* share a branch?

[Michael Witten <mfwitten@gmail.com>]

On Thu, 5 Apr 2012 13:48:23 -0700, Hilco Wijbenga wrote:

> 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.

I think you can keep doing what you're doing, but simplify the
management. I try to express this more precisely below.

Take all this with a grain of salt; it's kind of off the top of
my head, untested, and probably wrong (all the more so, because
it has been a while since I had to think about these commands
or workflows). Sorry if this is no different than what you're
already doing.

For a branch head `X' and a branch head `Y', let:

  X > Y

mean that X should be periodically rebased on Y.

Your team could have the following repository (that is,
there is a branch head `shared' and a branch head `master',
and `shared' should be periodically rebased on `master'):

  origin:
    shared > master

Developer `A' has a repository with a remote-tracking
branch `origin/shared', and a topic branch `local':

  A:
    local > origin/shared

Similarly for Developer `B':

  B:
    local > origin/shared

The concerns are separated as follows (I'm being a
little more explicit with the commands than what is
probably necessary):

  origin:
    git rebase master shared

  A and B:
    git checkout local
    # do some work with `local'
    # ...
    git pull --rebase origin +shared:remotes/origin/shared
    git push origin local:shared # If this fails, do the pull again.

In actuality, the `origin' maintenance can be done by Developer `A'
or `B', too; from one of their repositories:

    git fetch origin +master:remotes/origin/master \
                     +shared:remotes/origin/shared
    git checkout -b shared origin/shared
    git rebase origin/master shared
    git push origin +shared:shared
    git checkout local
    git branch -D shared

With a suitably set up configuration, you could probably automate a lot
of the command line arguments. For instance, if the `A' and `B' repos
have configurations that look something like the following:

  [remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    ...

  [push]
    default = upstream

  [branch "local"]
    remote = origin
    merge  = shared
    rebase = true

then the usual `A' and `B' workflow could simply be:

  git checkout local
  # do some work with `local'
  # ...
  git pull
  git push # If this fails, do the pull again.

and as for rebasing `shared' in `origin', at least the fetch would just
become just `git fetch'.

... I think...

Sincerely,
Michael Witten