On Monday 24 Jan 2011 23:44:44 Ian Clarke wrote: > On Mon, Jan 24, 2011 at 12:34 PM, David ?Bombe? Roden < > bombe at pterodactylus.net> wrote: > > > I have recently started using the branching model suggested by Vincent > > Driessen in http://nvie.com/posts/a-successful-git-branching-model/. At > > first > > the amount of branches that are created seem overwhelming but after a short > > time the benefits of having features cleanly separated before merging them > > outweigh the added complexity of the graph in gitk by far. > > > I'm all for doing things in ways that have been proven successful by others. > The current approach which involves a variety of independent repositories > does seem fairly peculiar.
Independant repositories for each subproject is sensible and normal practice. Now, to examine the page above: It is interesting that he endorses a push-based model, where many devs have push rights. This mostly works but it is tricky when a big change gets pushed and then undone in review. Generally the view is that it's better to just have many repo's and pull requests. Although right now quite a lot of people still have push rights. Some devs openly prefer posting pull requests. New devs are generally encouraged to branch via github and post pull requests. This certainly makes life easier for me with the current release process. If we did choose to continue with a many-push model, we'd probably want to set some rules about what branches you can push to. He uses "master" for the stable release, and "develop" for the latest pushed stuff. We use master on the stable repository for the stable release, and "master" on staging for the latest pushed stuff. So far so similar. Having said that, lately we use release branches a lot, which can diverge quite a bit from master. Feature branches I use in origin for larger changes, and a few other people do. Devs who post pull requests almost universally use feature branches. Feature branches are good, IMHO better than developing directly on master in most cases. Arguably they should be used for even relatively small features. Using the --no-ff option when merging a feature branch is a good idea. Release branchs are a good idea. At the moment I use release branches whenever I need to release some small part of what is on master. Wider use may make sense. I only update the version number at the last minute, which IMHO is better for our use as things may happen that make the branch planned to be a release actually into the following release. These are often, but by no means always, actually hotfix branches by his model. And of course we use signed tags for all releases, and for prereleases too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110212/e399e166/attachment.pgp>
