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. 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 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? 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. Thanks in advance, Bryan Drewery -- 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