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