Define Git Workflow
We will use simpler GitLab Flow with two main branches:
- master branch: we use as development branch on staging environment. Merging on master triggers deploy to stage
- production branch: create a version tag and merge master to production. This triggers deploy to production.
- temporary feature branches: they are merged into master with merge requests. Issuing merge request triggers tests on feature branch.
Branching models to consider:
- GitHub Flow = Git Feature Branch Workflow
- Atlassian Simple Git Workflow = GitHub Flow with Rebasing
- GitLab Flow
- Git Flow: most commonly used but sometimes too complex
Explanation: Merge or pull requests are the same thing, created in a Git management application. Devs ask an assigned person to merge two branches. GitHub and Bitbucket choose the name “pull request” since the first manual action is to pull the feature branch. Tools such as GitLab and others choose the name “merge request” since the final action is to merge the feature branch. But, it is the same action.
Things to do:
- Protect master info
- Explain the Merge Request procedure (with or without asignee as code review replacement)
- Each merge request must pass tests before it is accepted
About Git Flow
Development happens on the develop branch (using feature branches), moves to a release branch, and is finally merged into the master branch. Standard bugs are fixed on release branch and changes are merged back both to master & develop. Hotfix is used for urgent bugfix only on master branch, and also changes are merged both to master & develop.
- master: only used for production
- develop: where most of the development work occurs
- release: When all the features are done, you want to fix the bugs for these features. We are using separate branch as we want people to continue creating features as you fix bugs. Once the bugs are fixed, you’ll merge the release branch into master
More info:
There is options for Git Flow in Fork, SourceTree and GitKraken