git flow for great team collaboration

Version Naming Convention


  • x major version no., x++ when add a new module or need certain system re-structure
  • y minor version no., y++ when complete a new feature
  • x your workspace, z++ when fix a bug or issue

Branch Naming Convention

  • master branch: it is release-candidate space
  • dev branch: it is team workspace
  • feature-x branch: it is your workspace, “x” can be the Functional Spec id, name or short description
  • issue-x branch: it is your workspace

Commit Message

see one example first (from Angular open source):
Angular git commit msg

Commit message format:

<type>(<scope>): <subject>
// empty line here
// empty line here

type: the commit type, belongs to one of the following

  • feature: a feature
  • fix: a fix to bugs or something
  • docs: documentation (comments, etc.)
  • style: no impact to the runtime (change the coding style, etc.)
  • refactor: code refactoring (not to add a feature or fix a bug)
  • test: adding tests
  • chore: other things, such as changes of compiling, building, etc.

scope(optional): the software layer or component of the change, such as dao, controller, service, etc.

subject(optional): a short description, less than 50 words

  • start with verb
  • lower case
  • no full stop “.”

body(optional): detailed description
one special case for body is if this commit is to revert the previous commit, start with “revert:” and follow previous commit header, e.g.

revert: feat(pencil): add ‘graphiteWidth’ option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

footer(optional): only use in these two situations -

  • breaking change, e.g:

    BREAKING CHANGE: isolate scope bindings definition has changed.
    To migrate the code follow the example below:
    scope: {
    myAttr: ‘attribute’,
    scope: {
    myAttr: ‘@’,
    The removed inject wasn’t generaly useful for directives so there should be no code using it.

  • closing issues, e.g:

    Close #123, #245, #992

Git Flow

git flow

Team Lead

create the repo and dev branch

  1. clone the repo
    • git clone
  2. create dev branch and make it “track” a remote branch
    • git checkout -b dev
  3. publish to remote server
    • git push -u origin dev
    • git branch -a

do code review and sanity checking before merge request

  1. pull dev updates from remote server
    • git checkout dev
    • git pull
  2. checkout feature-x
    • git checkout -b feature-x
  3. pull feature-x updates from remote server
    • git pull origin feature-x
  4. try to merge dev and feature-x
    • git checkout dev
    • git diff dev feature-x
    • git merge feature-x
    • reviewing code, compiling, testing, etc.
  5. delete feature-x on local and remote server
    • git branch -d feature-x
    • git push origin :feature-x
  6. repeat 6-8 if there are new merge requests

Gitlab Server

  1. create merge requst
  2. merge request
  3. after successful CI, tag & merge dev to master


  1. clone the repo
    • git clone
  2. create dev branch and make it on “track” a remote branch
    • git checkout –track origin/dev (track a remote branch)
  3. pull dev updates from remote server
    • git pull
  4. create feature-x branch
    • git checkout -b feature-x dev
  5. now working on feature-x branch
    • do development, compiling and testing
    • git add …
    • git commit …
    • git status
  6. pull dev updates from remote server
    • git checkout dev
    • git diff dev origin/dev
    • git pull
  7. switch to feature-x
    • git checkout feature-x
  8. merge the updates from dev branch (solve any merge conflict)
    • git diff
    • git rebase dev
    • repeat 6-8 until no more new conflicts
  9. publish feature-x to remote server
    • git push origin feature-x
  10. delete feature-x and go back 3 for a new feature development
    • git branch -d feature-x
  • always working on local feature-x or issue-x branch !!!
  • every time before pushing, always pull from remote to local dev branch, merge it into feature-x branch:
    • resolve any conflicts
    • make sure at least no compiling errors, pass all unit tests, etc.
  • never commit or push directly to master branch !!!


  1. Lock the dev branch
  2. Merge dev into deploy branch
  3. Build and run test suite on deploy branch
  4. Deploy “deploy” branch to env (sit or uat), monitor any problem
  5. Merge the dev branch into master and tag it
  6. Unlock the dev branch