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.
We use GitHub to host and manage all of our project repositories, and it’s required that all developers ensure that project repositories are stored within the companies GitHub team account to allow all members of the development team access to be able to collaborate towards the development.
It is also required that all project repositories are set to private and include a supporting README.md file. The README.md 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.
We adopt the GitFlow branching model to manage our source control and versioning of our development files. It is required that developers follow this approach to organise the scaling of the development with multiple developers working on the project, and will allow for better maintenance for stable development.
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 https://datasift.github.io/gitflow/IntroducingGitFlow.html
Please see below some helpful git commands that could be used throughout the project to manage the source control and versioning:
Set upstream origin for all branches:
git config --global push.default current
Create new branch:
git checkout -b BRANCH_NAME
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 .