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