Git Workflows for Data Professionals
This quick introductory article to Git Workflows it’s a good starting point for those who want to become more confident about code versioning.
Since the following methodologies are broadly adopted by the majority of developers over the world, it’s not a bad idea to follow suit :)
My personal work experience primarily resides in adopting the Feature Branch Workflow model. I’ve followed that approach for more than 3 years at DAZN, working with data scientists worldwide.
Essentially, that method involves one mid-long life branch per feature that lives until the development is completed. Moreover, since the development is on another branch than the main branch, it never contains broken code.
This approach might sound time-wasting but the opportunity of working at the same time on different features on the same project is worth all the branches created! Moreover, reviewing merge requests and receiving feedback from colleagues is priceless.
On the Agile side, adopting a git workflow strategy is also very effective for tracking feature development.
Why should data teams adopt git best practices?
Following a git workflow strategy helps the team to work in the same direction:
developing maintainable and trackable code.
Get Fabio Barbazza’s stories in your inbox
Join Medium for free to get updates from this writer.
Since implementing a new feature may require several days/weeks, it’s very important to maintain the new implementation outside of the production code base.
Which branching models to adopt?
Feature Branch Workflow strategy is characterized by long-term branches that might be merged into the main.
In the Gitflow Workflow model, the feature release is not directly pushed into the main branch but is merged respectively into the development and the release branch.
Finally, I can not mention the Trunk Based Development workflow model where developers merge frequent small branches into the trunk branch. This is probably the newest and most adopted model.
