On 05/20/2013 10:15 AM, Petr Prikryl wrote: > Hi, > > Peter Morgan wrote: >> Best give I can give is to have the branches >> - master = the latest stable release >> - next = the next version and unstable > I am not that sure about the neccessity of > the branches when moved to Git. They should > probably be created only when the branch > is found to be neccessary. They can mostly > be local only. > > I suggest to use GitHub fork mechanism to > keep the project responsibility firmly > in Dimitri's hands (at least at the beginning). > The Pull Request seems to be visible enough > to decide whether to pull or not, or to use > only some changes... > > However, I have only limited experience > with Git, and I can be wrong ;) > > Petr >
One of the challenges with git is that is flexible and allows for many work flows. There isn't one "right way", but there are some common workflows. The most common workflow that I have seen is as follows: * most or all development happens on the master branch * each new feature gets it's own branch, which is merged or rebased with the master branch when it's mostly complete and doesn't break the build. * releases are cut as tags from master or from a version branch or stable branch(i.e. potential branches: master, stable, 1.2.x, 1.3.x, tags: 1.2.1, 1.2.2, 1.3.1) My advice is somewhat contrary to Peter's: * branches are awesome, use them whenever developing a new feature. Local branches can easily be discarded if things don't work out. Use public branches in the git repo with some reservation, * You should use a new feature branch for each new feature in your local repo. Once the feature is ready for merging, then merge/rebase and push the changes to github. * Using a branch allows for you to easily switch between various works-in-progress. Peter's next+master workflow is what the Linux kernel uses. It kind of mirrors master+stable branches in other projects. One alternative workflow is called git-flow, which is outlined here: http://nvie.com/posts/a-successful-git-branching-model/ One of the best ways to develop is using a continuous integration model. In this model, each commit to "master" is compiled and run against a series of tests, to determine if the project is viable. Travis CI offers free continuous compiling/integration for open source projects. It even integrates with github: https://travis-ci.org/ Jason ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Doxygen-users mailing list Doxygen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/doxygen-users
