-
Notifications
You must be signed in to change notification settings - Fork 2
Codebase and Gitflow
Based on the 1st factor of the twelve factor app, the codebase of our web, or else Software as a Service, application is tracked in a version control system like Git.
We are assuming that there is a one to one correlation between the app and a repo. Multiple codebases (and repos that is) is a distributed system and to that extend distributed twelve factor apps, while multiple apps, sharing the same codebase, is a violation of the twelve factor principle and instead dependencies should be used in order to share code between apps.
For every codebase, there can be many deploys (running instances) of the app to different sites or else environments. The codebase is the same, but different versions may be deployed to different sites, based on which commits were active at the time of deployment.
For Git management, a successful branching model that is known as Gitflow (original blog post and Atlasian tutorial).
In Gitflow there are two main branches with infinite life time:
masterdevelop
Other branches created locally (usually) and with shorter life span are:
- Feature branches
- Release branches
- Hotfix branches
The master branch is associated with the production environment, while branch develop holds the latest delivered development changes. In a continuous integration/continuous delivery (CI/CD) system, the code in the develop branch will be automatically built, tested and deployed to the staging environment and the master to the production server.
We are assuming we have setup a git repo with a master branch and remote tracking. We start by creating a develop branch and pushing it upstream:
git branch develop
git push -u origin develop
- Let's say I want to develop a new feature. First I check out develop:
git checkout develop - While in the develop branch do a
git pull origin develop, in order to get any changes made in the remote repo by others. - I create a new local branch from develop to work on the new feature:
git checkout –b feature1 - Then you start the development and testing of your feature1
- Use
git addandgit committo commit your feature1 changes. - When you are finished with feature1, switch to develop branch:
git checkout develop - Do a
git merge –no-ff feature1, to merge the changes by maintaining the branch of change with no fast forward or not maintaining it with:git merge feature1 -
git branch –d feature1delete the merged branch -
git push origin developpush to remote repository so that others (and the CI/CD system) to be able to access your changes.
Release and tag branches are used to track releases (deployments) of the master branch.
- We start by checking out develop branch:
git checkout develop - We create a release branch:
git checkout -b release-0.1.0 develop - We are making any changes needed in the release branch, like bumping up the version number through a script:
./bump-version.sh 0.1.0 - Add/Commit the changes:
git commit -a -m "Bumped version number to 0.1.0“ - Then we checkout the master branch:
git checkout master - Merge the release branch with or without
--no-ff:git merge --no-ff release-0.1.0 - And push the changes:
git push origin master - We can also tag the release:
git tag -a 0.1.0 - Push the tag to remote:
git push origin 1.2orgit push origin --tags - Checkout develop:
git checkout develop - Merge the release back to the develop branch as well:
git merge --no-ff release-0.1.0 - And push the changes:
git push origin develop - Delete the release branch since we don't need it:
git branch -d release-0.1.0
Hotfix branches are used to make a quick patches to the master branch/production releases, usually due to an urgent bug. They are similar to feature and release branches but they start from master, since the master is in trouble...
- We branch off the
masterbranch:git checkout -b hotfix-0.1.1 master - Make any changes:
./bump-version.sh 0.1.1 - Add/Commit:
git commit -a -m "Bumped version number to 0.1.1" - Make the fix.
- Commit the fix:
git commit -m "Fixed severe production problem“ - Checkout master:
git checkout master - Merge the hotfix:
git merge --no-ff hotfix-0.1.1 - And push the changes:
git push origin master - Tag it:
git tag -a 0.1.1 - Push the tag to remote:
git push origin 1.2orgit push origin --tags - Checkout develop:
git checkout develop - Merge the hotfix to develop as well:
git merge --no-ff hotfix-0.1.1 - And push the changes:
git push origin develop - Delete the hotfix:
git branch -d hotfix-0.1.1
It is a good practice to write good commit message and to include the issue number in the message when making a commit. For example: git commit -m "message issue #3", in order for this specific commit to be associated with issue #3.
- Download reference cards: http://help.github.com/git-cheat-sheets/
-
git statusWhat has changed since the last commit? -
git branch -aCheck out all the branches (local and remote) -
git remote -vCheckout all the remotes
There are many resources over the web for writing good commit messages. Be sure to check them and choose one style that suits you.
Table of Contents:
- Agile Project Management
- Codebase and Gitflow
- Environments
- The MERN stack
- Developer setup
- Testing
- CI and CD
- Example Application
- Security
Under construction: