On Sun, Sep 5, 2010 at 2:35 AM, Bryan Drewery <bryan@xxxxxxxxxx> wrote: > Hi, > > I maintain a project at work using a similar workflow as git.git with 6 > developers; I've > read gitworkflows(7) and several of Junio's emails regarding his > workflow. The project > is still maturing so we have frequent API/DB changes and do not maintain > backwards > compatibility very well. > > Developers base their topics off of Next, due to the frequent API/DB > changes not in Master, and > are able to merge their topic branches into Next themselves once > completed. They rebase > their topic on top of Next at this point. They can't necessarily rebase > on Master here because > they may hit conflicts due to code not existing in Master yet. > Basing on next is fine, provided you never rebuild next. But if you never rebuild next, then it isn't really acting like a next branch - it really is master.If you do rebuild next occasionally, then you are asking for trouble because changes you thought were reverted out of next will flow back via branches that were forked from the earlier version of next (unless you are rigourous about which changes you accept into next) If you can do team-wide daily or twice daily builds, tag those, and ask your developers to base all their work on those tags. Tags are inherently stable and well specified. A branch is inherently unstable and ill-specified [ When you say you based on next, what commit do you mean exactly? Next on which machine? Next at what time? What is the pull history of that machine and the machine it pulled from? ]. > This is my first problem, once the branch is ready to merge into Master, > I have to rebase > it on top of Master, then merge in, merge Master down into Next; > polluting the history in > Next with duplicated commits. > The first problem is the rebase onto master. If you are doing this, you are guaranteeing a world of pain. You should be merging into master. If a topic's base is a previous tag from master plus a selected number of other fixes, then merging such topics into master should be a no-brainer. Of course, if people are basing their work on something unstable like next, then their work will contain all measure of untested nastiness and a merge into master won't be practical. This is another reason to encourage developers to base their work on a well-known, stable tag, and not the bleeding tip of some integration branch like next. Rule of thumb: never rebase anything that has been shared with anyone else. If you are merging a change into next and then rebasing it onto master, you are breaking this rule. Rebasing is great and I do it often, but I keep such things to myself. > The other problem is that once their topic has been merged into Next, > and before it has > been merged into Master, it may be found that another commit is needed > on their topic > to fix an issue. Due to frequent API/DB changes, they might 'git pull > Next' into their topic > branch, so they can properly test the new fix. Obviously this makes > things difficult once > the topic is ready for Master, and I have to manually cherry-pick their > commits into a > new branch to get rid of the 100s of Next commits they merged in. > > What's the best solution for handling this? Should we just be resetting > Next after releases > to remove the pollution? If the topic is based on a well known tag, the topic does not contain merges from anything other than the well known tag and a handful of other topics, then the answer is to simply update the topic with the fix and then remerge the topic into master (and into next and into any other dependent work). > > I'm thinking that we need to incorporate subsystem maintaining/branching > as well, and > group up like subsystem changes into the same releases. Though we still > run into problems > where every file in the system needs updating for new API. Perhaps our > workflow is just completely > wrong? > > Any input would be appreciated. > I also wrote a post a little while back about maintaining a private working branch: http://permalink.gmane.org/gmane.comp.version-control.git/153168 The idea is that each developer maintains a base branch, all dependencies are merged into that base branch and all their work is performed ontop of that base. As the work is stabilised, it is rebased onto topic branches based on well known tags and these topics are then published. The basic ideas is always merge into the _base_ of the working branch , never merge into the _tip_ and never publish the tip of the working branch. jon. -- 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