Version 8

    Since we don't like to reinventing the wheel and thus we want to follow successful paths, we have adopted Successful Git branching model. You can read about it also in article Why aren't you using git flow?, watch the screenscast as practicing show and also it is possible to use tools to support this model - Git command-line tool.

     

    RichFacesWorkflow.png

     

    Branches in Detail

     

    Branch master is the base for stable releases and contains major and some of minor tags.

     

    Real development happens on develop branch, which is the final point for introducing new features.

     

    feature branches are created for work on introducing all new features and also for  investigations when fixing a bug (except the trivial ones).

     

    release branches are created either from develop (major releases) after stabilization process or from tag (minor releases).

    These branches going through release process, release testing and stabilization.

     

    Naming Conventions

    release branches are called as the release version they are introducing:

     

    release/4.2.0.Milestone1
    release/4.1.1.CR1
    

     

    feature branches are called as the issue that have introduced them:

     

    feature/RF-11029
    

     

    All of supporting branches may be published locally to personal Git repositories to develop in distributed fashion.

    Issue Workflows

     

    We have distinguishing two workflows based on role in the project:

     

    • commiters acts as integration managers - have write access to project repositories
    • contributors can't write into project repositories directly, but can open pull requests

    Commiter Workflow

    1. issue assigned
    2. create feature branch
      • feature should not span more than one repository
      • create new  issue or subtask for modifications which spans more than one repository
    3. work on issue
    4. rebase changes against develop
    5. push to master
    6. resolve issue

     

    Contributor Workflow

    1. fork master/develop (see "What branch to fork?" bellow)
    2. create feature branch
    3. fix an issue
    4. create issue (when working on issue which doesn't exist)
    5. rebase changes against develop
    6. push to personal GitHub repository
    7. send pull request on GitHub against develop branch
    8. link pull request in JIRA (use Workflow button in issue)
    9. let integration manager review you commit
    10. (optional) update code according to comitter's notes, rebase, send and update pull request in JIRA (Workflow button)
    11. let integration manager merge your changes to develop
    12. integration manager closes pull request in JIRA (effectively resolving the issue)

     

    What branch to fork?

    You can fork either develop branch or master branch, based on type of contributement you want to do.

     

    1. fix an localized issue
      • fork master (or tag)
      • branch is stable
      • you can verify it in your application
      • all unit tests have to pass before rebase
      • rebase against develop may be complex and require integration manager help
    2. fix an complex issue
      • fork develop
      • recommended: run unit tests on your fork to be sure unit-tests passes
      • you are at cutting edge on development
        • rebases are simple than in (1)
        • you are not shielded from regressions made in branch

     

    Release Requirements on Workflow

     

    Proposed model is reflecting following requirements:

     

    1. development for version
      • component freeze
      • feature freeze
      • stabilization phase
      • the length of each phase depends on the stage of the project (Milestone, CR, ER, Final)
    2. release versioning
      • major releases
        • diverged from develop
      • minor releases
        • fixes incorporated into develop may be ported to new minor release
        • late decision about minor release
    3. release testing
      • bug-fixing and stabilization
        • diverge release branch after release meets QA release criteria
        • stabilize branch separately
      • don't influent feature development
        • develop branch open after diverging release branch