Just for add a bit of documentation for helping discovering the best workflow:
http://nvie.com/posts/a-successful-git-branching-model/ The post contains some good points in my opinion, for example the guideline that a feature branch have to exists in developer repo and not in origin. ciao Attilio On Sat, Feb 21, 2015 at 7:02 PM, Martine Lenders <mlend...@inf.fu-berlin.de> wrote: > Hello coding RIOTers, > After I needed to rebase several PRs multiple times last week I'm really > fed up with our current workflow. Furthermore, I discovered three things > that show that we are in need of a more established workflow. > > 1. our community is growing > 2. our master branch is changing constantly and has features in it > that are sometimes thrown out the window weeks after they where introduced > (e.g. radio_types.h or the older versions of netapi/netdev) > 3. we introduced feature-centric task forces to our communities > > This is why I propose we change to a slightly adapted topic branch > workflow (also known as feature branch) workflow [1]: > > - the main RIOT-OS/RIOT repository will get the following branches > - master: points to the stable version of our latest release > - one stable branch for every major release (?) > - devel: points to current development version (what is currently > our master), hot fixes can be cherry-picked to the master from here. > - branching from devel: feature branch for every task force that is > currently in active development, current changes will be merged > regularly > from devel by the branches maintainers > - Pull Requests will be made either to devel (default) or the > corresponding feature branch > - feature branches will be merged into devel if the feature reaches > sufficient stability. > - devel will be merged into master, when a new release is out and > master's new HEAD tagged with the release number. > > I observed two extra benefits from that: > > - accidentally merged "SQUASH ME" commits can be squashed further > upstream, before we add the commits to master or devel > - we can make maintenance of features more granular (and maybe solve > our maintenance problem) by enacting the "Dictator and Lieutenants > Workflow", where the "Dictator(s)" are responsible for master and devel, > and the feature branches can be maintained by the central persons of the > Task Force (the Lieutenants). > > What do you think? > > Cheers, > Martine > > [1] > http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows#Topic-Branches > [2] > http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow > > _______________________________________________ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
