Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
L limbra
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 15
    • Issues 15
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • limbra
  • limbra
  • Wiki
  • branching_model

Last edited by LE GAC Renaud Jun 02, 2015
Page history

branching_model

Branching model

  • The branching model described in http://nvie.com/posts/a-successful-git-branching-model have been adopted. It relies on the branches: master, develop, feature, hotfix and release.
  • In May 2015, the git repository has been migrated to GitLab.
  • The branching model can be simplified using the GitLab functionalities issues tracking and merge request as recommended in http://doc.gitlab.com/ee/workflow/gitlab_flow.html.
  • The branching model is based on two stable branches master and production.
  • Each code modification (bug fix, improvement, ...) start with an issue.
  • For each issue a feature branch is created. Its name starts with the issue number.
  • When the code for the issue is finished, the branch is rebased with respect to the master one and then pushed in the master branch via a merge request. The merge request description has to contains the issues number (fixes #14 (closed), closes #67 (closed), etc.). The issue has to be closed and the branch has to be deleted when the merge request is accepted.
  • When the master branch reach a point corresponding to a release, it is pushed in the production branch via a merge request and tag.
  • An hot fix start by an issue. It is prepared in a dedicated branch. Once ready the dedicated branch is push to the master via a merge request (conflict might be solved at that time). The hot fix branch is pushed to the production branch when the hot fix is working in the master branch. Then the hot fix branch is deleted.
Clone repository
  • CheckRelease
  • DocumentingPythonCode
  • HarvesterLogic
  • InstallJsduck
  • InstallSenchaCmd
  • MariaDB
  • Migrate0811
  • Migrate0900
  • PyTest
  • RoadMap
  • YumAutoUpdate
  • api_inspirehep
  • branching_model
  • Home