Backend Knowledge Sharing #27

Comparing Git Workflows

Here at Younginnovations we’ve been working together over many projects of different size and type, continually evolving and improving the way we collaborate. Upon hearing ‘collaborate’ we usually think of words like manager, milestone, sprint, scrum and so on. This week, we focused on stuff related with code collaboration: introducing changes, solving conflicts, using branches, and more.

Every team has its own workflow based on the type of project, company size, team preferences, and many other things. The bigger the team, the harder it is to keep everything under control: problems with conflicts become more common, release dates need to be postponed and priorities keep getting changed on the fly.

Employing Git solves the basic issues with code collaboration but it is not always enough. Given Git’s focus on flexibility, there is no standardized process on how to interact with Git. When working with a team on a Git managed project, it’s important to make sure the team is all in agreement on how the flow of changes will be applied. To ensure the team is on the same page, an agreed upon Git workflow should be developed or selected.

Git is not opinionated, but lots of people have opinions about how you should do it.

Git Workflow

Our source control workflow is a big part of our project development workflow, so it has a big impact on developers day to day quality of life. A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner.

Git workflows encourage users to leverage Git effectively and consistently. Ideally our Git workflow is going to align well with our business processes, so it’s good to take a look at the most common strategies rather than blindly pick what you think is the most popular.

1. Centralized Workflow

The Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project. The default development branch is called master and all changes are committed into this branch.

This workflow doesn’t require any other branches besides master. The central repository is *the* official project and should be treated as sacred and immutable (i.e. no rewriting history).

How it works

• Clone the repository (i.e. git clone).
• Make, stage, and commit changes. (i.e. git add, git commit).
• Merge in the latest from the central repository (i.e. git pull).
• Use git pull –rebase to move all of your commits to the tip of the history.
• This will allow you to handle any conflicts on a case by case basis.
• Push changes (i.e. git push).

This is a easy to understand workflow, great for small teams or projects (i.e. few contributors). But, resolving conflicts can be a burden as the team scales up.

2. Feature Branch Workflow

Feature Branching is a logical extension of Centralized Workflow.

The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main code base.

It also means the master branch should never contain broken code, which is a huge advantage for continuous integration environments.

How it works

• Start from master (i.e. git checkout master).
• Create a new branch off of master (i.e. git checkout -b MyNewFeature).
• Similar to before, make, stage, and commit changes (i.e. git add, git commit).
• Push your new branch to the remote (or centralized) repo (i.e. git push origin MyNewFeature).
• Use the tooling of your repository management system to create a Pull Request / Merge Request.
• Note that if there are conflicts, those will need to be corrected locally (i.e. git pull –rebase again) and the feature branch re-pushed.
• Prior to the pull request, if another developer wanted to contribute to the feature branch, they could pull it locally to contribute to it (i.e. git pull MyNewFeature) assuming the feature branch has already been pushed to the centralized repository.

3. Gitflow Workflow

The Gitflow Workflow defines a strict branching model designed around the project release. 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.

Develop and Master Branches

Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It’s also convenient to tag all commits in the master branch with a version number.

Feature Branches

Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master

Release Branches

Making release branches is another straightforward branching operation. Like feature branches, release branches are based on the develop branch. Creating this branch starts the next release cycle, so no new features can be added after this point — only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it’s ready to ship, the release branch gets merged into master and tagged with a version number and then deployed. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release.

Hotfix Branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they’re based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle.

How it works

There are so many commands involved in Gitflow workflow because of the many steps involved and strict branching concepts followed. See Atlassian’s write up for a complete walk through of this workflow with the necessary commands.

Some Useful Links

1. https://github.com/docker-slim/docker-slim: Minify up to 30x and Securing Docker containers without changing anything in your Docker container image
2. https://github.com/trekhleb/javascript-algorithms: Algorithms and data structures implemented in JavaScript with explanations and links to further readings
3. https://github.com/luka1199/geo-heatmap: A python script that generates an interactive geo heatmap from your Google location history data.
4. https://github.com/microsoft/api-guidelines: A REST API design guidelines by Microsoft, which Teams at Microsoft typically reference when setting API design policy.
5. https://github.com/kdion4891/laravel-ajax-crud: A Laravel CRUD generator from Model.
6. https://www.phpclasses.org/package/11463-PHP-Monitor-and-control-processes-running-on-a-servers.html: A PHP package to Monitor and control processes running on a server.
7. https://github.com/MTrajK/coding-problems: Solutions for various coding/algorithmic problems and many useful resources for learning algorithms and data structures
8. https://github.com/sindresorhus/awesome: Awesome lists about all kinds of interesting topics.
9. https://github.com/ryanmcdermott/clean-code-javascript: Clean Code concepts adapted for JavaScript
10. https://github.com/eriklindernoren/ML-From-Scratch: Machine Learning From Scratch. Barebones NumPy implementations of machine learning models and algorithms with a focus on accessibility. Aims to cover everything from linear regression to deep learning.

If you are still going, 😉 You can checkout our previous blogs 👇,

Frontend-Design Knowledge Sharing #27

Backend Knowledge Sharing #26