Patrick Aljord wrote:
Hey all, We are 3 developers working on the same project. I was thinking what would be the best practice for us. We have just switched from svn and for now we are all working on the master branch that we push to a ssh git repository. I was thinking about maybe each of us could create our own branch like 'git branch <dev_name>' but then how would it go? Each one of us would push our own branch to the remote repository and each one of us could cherry pick the change from the remote branch of each developer. Is this the best way to do it? (I guess there is no best way but still :) any advice welcome
This is what we do at work. We're 3-6 developers on each project, and each of us have our own branch, into which we merge our topic-branches. Someone is then designated integrator of the project, and responsible for merging branches or cherrypicking commits into master. In our case, we use 'testing' rather than 'master', to denote that the test-department should take over and try out all the features/fixes we've added. The test-team only ever gets email when something ends up on their branch, so notifying them that they have some new work in their pipe is done automagically. The test-team then reports back to the integrator, who either merges the testing branch in its entirety into master, or cherry-picks such isolated commits as are working properly. Usually various topic- branches are pulled into master. Once one cycle of development is finished (ie, a roadmap waypoint is reached and we're getting close to release), the integrator tags the master branch. A new tag, reachable from the tip of 'master' automagically sets off the build-machinery, which delivers a packaged version of the software back to testing for further delivery to test-customers. Once those customers report positive results back in, we retag the same commit we shipped, but without the rc-suffix, making the package building machinery this time send the package to the support-team, which releases it to every customer interested. That turned out to be quite a lot of text... Anyways, the above works really well as there's no risk of us forgetting to send emails, or forgetting which features are where. It's also nice from a developers POV, as we only have to worry about the code and the tool we use to track it. It does force us to write clear and concise commit-messages to avoid unnecessary questions from the testing team, but that's a sensible thing to do anyways. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - 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
