GitFlow VS Trunk-Based-Development
A. Version Control System
Nowadays, versions control system (VCS) take important role in software engineer main tools to keep source-code management (maintainable purpose). There are some popular VCS on public such as CVS, SVN, Git, etc.
In this article we will focus using Git version control to explain every examples about VCS Methodology.
B. VCS Methodology
B.1. GitFlow
Gitflow is branching model for Git, created by Vincent Driessen. It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team.
Gitflow management designed to manage git branching and release management workflow that helps developers keep track of features, hotfixes and releases in bigger software projects. This workflow has lot of commands to type and remember, so there’s also the git-flow library of git subcommands to help automate some parts of the flow to make working with it easier.
How this flow works?
- Developers create feature branches from master branch and work on them. Once they are done, they create pull requests.
- In pull requests, each developers comment on changes and may have discussions.
- Once it’s agreed upon, the pull request is accepted and ready to be merged to the main branch. (There is/are a developer whose in charge for main branch management).
B.1.1 Advantages
- Project type : open-source
- Team size: no limit (small, medium, large)
- Developer experiences: suitable for team with a lot of junior developer
- Suitable for product development that already established before.
B.2.2 Disadvantages
- Not suitable for starting-up development
- Reduce development-speed on fast iterations.
- Senior developer would easy to feel uncomfortable (due to strict control).
- Flow visualization looks very complex
B.2. Trunk Based Development
TBD is a source-control branching model, where developers collaborate on code in a single branch called “trunk” (master, in Git nomenclature), resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
How this flow works?
- Developer start work on main branch or create short-lived-feature branch (a branch from trunk) and start work on them.
- Once they are done with compiling and all testing, they push all changes to trunk (or merge to trunk) directly (without make a pull-request).
TBD a key than enabler of Continuous Integration (by extension Continuous Delivery). When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.
B.2.1. Advantages
- Project-type: closed source
- Suitable for starting-up development
- Support fast iteration development
- Developer experiences: suitable for team with a lot of senior developer (no need strict control).
- Flow visualization looks very simple
B.2.2. Disadvantages
- Not suitable for open-source development
- Not suitable for team with a lot of junior developer
- Not suitable when we have established product or manage large teams that implement strict-control due to business needs.
Conclusions
Each VCS methodology has it’s own pros and cons, we need suitable methodology based on project requirement (project type, team experience, iteration type, product scale).
Glossary
- Trunk
In the world of software development, “trunk” means main development branch under a version control system. It’s the base of a project, where all improvements are being merged together.- Branch
Branches are created from the base project, in order to develop a new feature, fix a bug, or simply do some refactoring. They prevent software developers from disturbing each other and enable them to work in parallel. Once a change is finished and tested, the branch is merged back to the trunk.- Feature Branch
The feature branch has a clear and highly-focused purpose—to add specific functionality to a project. It shouldn’t contain any other changes that fix bugs, introduce other features, or are part of a refactoring.