Changes between Version 7 and Version 8 of StartModWorkflow


Ignore:
Timestamp:
Dec 10, 2013, 3:46:17 PM (9 years ago)
Author:
Beman Dawes
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • StartModWorkflow

    v7 v8  
    33
    44Workflow is the term used to describe the steps a Boost library developer follows to create and maintain a library.
     5
     6== Git Flow ==
    57 
    6 The workflow model Boost recommends is nowadays called '''Git Flow'''. It was introduced as a simple [http://nvie.com/posts/a-successful-git-branching-model/ blog posting] by Vincent Driessen on January 5th, 2010, that went viral and has become a widely used software engineering practice.
     8The workflow model Boost recommends is called '''Git Flow'''. It was introduced as a simple [http://nvie.com/posts/a-successful-git-branching-model/ blog posting] by Vincent Driessen on January 5th, 2010, that went viral and has become a widely used software engineering practice.
    79
    810This workflow has arguably become so successful because it scales well from very small to very large projects, and that's one of the reasons it is recommended (but not required) for Boost libraries.
     
    1416The Git Flow model diagram is available as a [http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf PDF file] - print it out and hang it on your wall!
    1517
     18== Command line tools ==
     19
    1620For those who use Git from the command line, [https://github.com/nvie/gitflow git-flow command line tools] are available to automate common operations. See [https://github.com/nvie/gitflow/wiki git-flow wiki] for more information.
    1721
     22== Branch names ==
     23
     24All Boost libraries are required to have two branches:
     25
     26* {{{master}}} is always the library's latest release. It should always be stable.
     27* {{{develop}}} is always the main development branch. Whether it is always stable or not is up to the individual library.
     28
     29 These branches are require so that Boost's release management and other scripts can use known branch names.
     30
     31While Boost libraries are not required to use the following branches, it is strongly encouraged that these naming conventions are followed if the branches are present.
     32
     33* {{{feature/descriptive-name}}} for feature branches. For example, {{{feature/add-roman-numeral-math}}}.
     34* {{{bugfix/descriptive-name}}} for bug-fix branches, including hotfixes. For example, {{{bugfix/ticket-1234-crash-if-result-negative}}}
     35* {{{release.n.n.n}}} for release staging branches. For example, {{{release.1.56.2}}}.
     36 
    1837== Aside: Deleting merged branches ==
    1938
     
    2443keeps the commit history alive and there's no longer any need to keep
    2544the old label around.  If you delete a branch without merging it, of
    26 course, any commit history exclusively referenced by that branch is
     45course, any content and commit history exclusive to that branch is
    2746lost.
    2847