The git workflow I am proposing here is a mixture between both the Gitflow Workflow and the Feature Branch Workflow. The reason for not using either is because I like the simplicity of the feature branch workflow as well as the robustness of the Gitflow workflow, but they both do not seem to fit the needs of a fast moving agency completely. I have therefore tried to take the best out of those two and adapt it to my or rather our company's needs.
Sometimes it is hard to maintain a proper development, test and release cycle. This can be due to many facts, but in my opinion mostly because of the following reasons:
- Multiple features being worked on at the same time which all have to be deployed to a testing environment for QA
- Features are getting pulled back or put on hold (by the QA, PM or even the client)
- Features are blocking other features on the release branch
The Gitflow Workflow still uses a central repository as the communication hub for all developers. And, as in the other workflows, developers work locally and push branches to the central repo. The only difference is the branch structure of the project.
At the core, this model uses two main branches: master and develop. The rest of this workflow revolves around the distinction between these two branches.
A historical branch with an infinite lifetime. It is used to record the history of the project and will be deployed to a live/production environment, so the HEAD of origin/master should always reflect a production-ready state.
The integration branch with a finite lifetime. This branch should always be ahead or even with the master branch. It is deployed to a developing environment and should never be merged into anywhere.
It should be recreated of the master branch as soon as testing is done and the changes have been merged into the master branch to keep a certain overview.
The develop branch can be used for testing; but note: Any commit made to the develop branch directly will never be cherry-picked or "merged out" onto master or any other branch.
Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. Feature branches will use master as their parent branch. Once a feature is complete, the developer should create a Pull Request into it's parent branch (master).
The code will then be reviewed and merged into the develop branch for testing. There's two reasons for that:
- The
developbranch is deployed to the development environment and the only way to test the feature on a production-like environment. - The
developbranch may has progressed since the feature was started
As previously stated above, feature branches created off the develop branch will not be merged into master.
Feature branches usually start with the prefix feature/ and a short but descriptive name, e.g. feature/custom-user-model.
Issue branches behave just like feature branches. Branch off and merge into master. The recommended prefix is issue/ to form a branch name like issue/. They should be used when you're fixing a bug rather than developing a new feature.
Hotfixes are done where there is an urgent issue on a production environment which has sneaked through QA, i.e. a server error by an incorrect setting which could not be tested properly before.
The behaviour here is just like the feature and issue workflow, but in certain cases it is also possible to commit to origin/master directly to fix the issue as quick as possible.
The example below demonstrates how this workflow can be used to manage a single release cycle. We’ll assume you have already created a central repository.
The first step is to ensure you're local repository is up to date with the remote. You can do this using either plain git:
git checkout master
git pullor a tool called git-up to take care of you're local repository - I've been using it for a while now and can only recommend it:
git upIn order to start working on a new feature, you need to create a new feature branch basing on master:
git checkout -b feature/something masterAdd commits to the feature branch in the usual fashion: edit, stage, commit:
git status
git add <some-file>
git commitAfter you've added your commits and your feature is ready, it is time to push that branch to the central repository and opening a pull request asking to review the feature:
git push origin feature/somethingThe pull request is now under review. Next to manual code review it can also be deployed to the testing environment by merging the feature branch into the develop branch:
git fetch origin
git checkout -b feature/something origin/feature/something
git merge develop
git checkout develop
git merge --no-ff feature/something
git push origin developAfterwards, deploy your updates to the testing environment.
If the feature passes review and QA, the reviewer may merge the feature into the master branch using GitHub's pull request interface. The production environment can now be deployed again.
Make sure to delete the feature/hotfix/issue branch after the pull request has been merged to keep the branch overview as clean as possible. This can be achieved using GitHub's interface or through git:
git push origin :feature/somethingA short comparison from the two workflows which gave inspiration, taken from the Atlassian Git Tutorial with slight adaptions.
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the
masterbranch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means themasterbranch will never contain broken code, which is a huge advantage for continuous integration environments.
Encapsulating feature development also makes it possible to leverage pull requests, which are a way to initiate discussions around a branch. They give other developers the opportunity to sign off on a feature before it gets integrated into the official project. Or, if you get stuck in the middle of a feature, you can open a pull request asking for suggestions from your colleagues. The point is, pull requests make it incredibly easy for your team to comment on each other’s work.
The Gitflow Workflow defines a strict branching model designed around the project release. While somewhat more complicated than the Feature Branch Workflow, this provides a robust framework for managing larger projects.
This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Of course, you also get to leverage all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration.
If you're not agreeing on something or want to suggest an improvement, please do not fear discussing it with me. I am very welcome for any suggestions (github.com/Chive).
Sources:
- Atlassian Git Workflow tutorial (https://www.atlassian.com/git/tutorials/comparing-workflows)
- Vincent Driessens's Branching Model (https://www.atlassian.com/git/tutorials/comparing-workflows)