Re: Linear history *and* share a branch?
- From
Michael Witten <mfwitten@gmail.com>
- Date
- Apr 6, 2012, 02:32 UTC
- Message-ID
- <c9ba22f806704f8689544d29455a242f-mfwitten@gmail.com>
- In-Reply-To
- <CAE1pOi0-uSaQwgJHMTkw3nqp=idxZxMbyfKtLni0=Xwu-L-_hA@mail.gmail.com>
On Thu, 5 Apr 2012 13:48:23 -0700, Hilco Wijbenga wrote:
Show 14 quoted lines
> 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 > masterDeveloper `A' has a repository with a remote-tracking branch `origin/shared', and a topic branch `local':
A:
local > origin/sharedSimilarly for Developer `B':
B:
local > origin/sharedThe 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 sharedWith 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 = truethen 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