Structure and principles for source control and versioning in a multi-team environment.

Most developers use Git to manage the source control of the projects development files which will allow versioning and the ability to revert back to previous versions of development if required.


It is also required that all project repositories are set to private and include a supporting file. The file includes all project relevant information outlining the technologies used and steps for getting the application running.

Repositories also include a .gitignore file to ignore all core files and any sensitive information from being tracked. It’s important that no files contain any logins and credentials for any accounts or connection details to any databases. Any sensitive information required for the project should be stored within environment files which will be git ignored.


The structure for GitFlow is as follows:

  • Master Branch
    The master branch will contain the master development files which will be pushed onto the production server for the application. It is required that no development is carried out on this branch, but merged into it from the release and hotfix branches.
  • Develop Branch
    The develop branch will contain the latest stable development files which will be merged in from feature and hotfix branches. Any new development features will be forked from this branch.
  • Release Branches
    Release branches will be created to store stable development files staged for deployment. It is required that this branch is fully tested and signed off before merging into the master branch. Development will be merged into release branches from the develop branch. This branch is deployed on the projects staging environment and signed off before merging into the master branch and deploying to production.
  • Feature Branches
    Feature branches will be created for all development features, each feature will be located within its own feature branch for better separation. It is required that all features are tested and signed off before merging into the develop branch and develop branch is tested once featured have been merged.
  • Hotfix Branches
    Hotfix branches will be created to store all development that has been done to resolve any bugs or issues with previous releases that may have been missed and deployed. Depending on what branch the bug is located within, hotfix branches should be forked off and merged back into the branch once the issue has been resolved, tested and signed off.

For more information and a detailed breakdown of the GitFlow branching model, please see

Git Cheatsheet

Set upstream origin for all branches:

git config --global push.default current

Create new branch:

git checkout -b BRANCH_NAME

Merge branch:

git merge BRANCH_NAME

Delete Local Branch:

git branch --delete BRANCH_NAME

Delete Remote Branch:

git push origin --delete BRANCH_NAME

Change commit message:

git commit --ammend

Flush Git cache:

git rm -rf --cached .
git add .

Stash changes:

git stash

Digital Strategy, Innovation, Business Development and Growth.