Company X has a problem. Their distributed team of developers are constantly introducing regressions into production with no clear point for QA to become involved and without a Git guru on the team, they are wasting time untangling commit conflicts. If this sounds like your team, then “git-flow” may be the solution.
Git lends itself well for use in a web development environment, particularly for distributed teams, given its distributed architecture and relatively short learning curve. This level of flexibility, however useful, creates complexity which, brings with it several challenges. Each team member, for example, may have their own preferred workflow with subtle differences in approach that could translate to complications for others.
Git-flow is a tool that manages the inherent chaos of a distributed team by applying a formal set of best practice conventions in an established workflow. Its main purpose is to enable development teams to be more efficient. Git-flow provides a well-defined path for developers to deliver tested and verified working code from a development environment to a staging environment to a production environment using established best practices.
The central idea of git-flow is to maintain two immortal branches, or “parallel lines of development”.
- master - This is where your “production” code lives.
- develop - This is where your team integrates their code and where QA would operate.
Any work that is done to extend the codebase is done in “feature” branches. A feature branch is where all active code work related to an individual task is done. This keeps the work abstracted from what other team members are working on. A developer would create a feature branch for a specific task or set of tasks then when those tasks are complete they merge the new code into the develop branch.
There are a number of alternative workflows out there, git-flow is a culmination of best practices and conventions that play well to the distributed web team. Git-flow coerces a single process onto the team, so that the details of the repo and release management are taken care of and developers can focus on their contributions.
Why should I care?
Standardizing your team’s approach to code deployment with git-flow prevents any up front “learning from mistakes” time that teams without a standard process inevitably encounter. With git-flow, your team benefits from the wisdom gathered through mistakes of others and starts them out on a well-established path toward clean and efficient code management. This means shorter time to productivity and higher development velocity. This translates to happier, more productive developers, more productive and efficient development cycles and ultimately more satisfied product owners.
What does this mean to my team?
- Learning curve to git is reduced due to distilling of complexity into convention.
- Fewer “accidental” releases.
- Greater confidence in the stability of the master branch and safe releases.
What do I need to do?
Git-flow doesn’t add any new functionality to git itself or the repo, it merely “wraps” some of the complexity by combining multiple commands into one and enforcing a workflow. Because of the way that it is built, a git-flow workflow can be started at any point.
Have your team review git-flow for daily use and review the documentation to begin an organized, sustainable approach to development.