Git Workflows

Git can feel overwhelming, especially for newcomers in software development. The deceptive part is thinking you’ve got it down by relying on a few common commands. However, as projects grow, unique challenges arise, demanding new strategies for collaboration.

Introduction #

This blog delves into git workflows: familiarizing you with their types, discussing pros and cons, and providing real-world examples. These insights help you harness your existing git knowledge to collaborate better in medium to large teams. Remember, these suggestions aren’t strict rules—choose what suits your team best.

Git Workflows #

Imagine collaborating with friends on a repository—one works on the master branch, another works on their own branch while the other forks the project. Maintaining this variety gets tough. Git workflows are recommended collaboration methods that ensure a team follows an agreed-upon approach. This simplifies teamwork, helping experts contribute consistently and identify who’s responsible for changes. Ultimately allowing you to collaborate like distinguished gentlemen.

Centralized workflow #

This workflow as the name suggests means that all the team members will work off a single branch more often than not the main branch. User A will clone the project and make their changes on the main branch, user B will also clone the project and make their changes on the project. If user A had already pushed their changes to the remote branch, then user B will be forced to resolve the conflicts before pushing their changes. This workflow is simple and most suitable if the size of the project and team is small.

Pros #

• Simplicity- It requires very little technical know-how.
• Developers resolve their own merge conflicts locally avoiding the overhead of automatic merge conflicts.

Cons #

• At a glance, one major challenge that can arise from this flow is complexity in the merge conflicts especially if the users work on issues that rely on each other.
• Limitation in what can be committed- Some commits may cause the main branch to be unstable so developers must ensure their changes do not have any bugs before pushing.

Feature workflow #

In a feature workflow, the developers create a branch with a descriptive name about the feature they are working on. For example in a repository with two users, one may decide to work on the login authentication feature, they will then create a branch named login-authentication. Another may decide to work on the registration feature they would create a branch named registration-authentication. Note that these branches would be created off the most stable release of perhaps the main branch.

Once they are done implementing these awesome features, they can then either do a rebase to update their version of main then push and make a pull request to merge their feature branch to main, or possibly get feedback from their fellow developers. This will ensure a linear history of commits for the main branch.

Pros #

• Separation of concerns- Developers need only be concerned about their feature branch
• Better collaboration- Once a developer is done with their feature they can create a pull request that allows others to review their code and add any comments they feel may be necessary.
• Maintains a clean main branch - Since all the changes are made on the feature branch and only stable features are merged into the main branch, the main branch is left stable and clean enabling better continuous code integration.

Cons #

• Burden on the developer- Since the feature branch always has to stay up to date with the main otherwise it will become outdated

Real-world projects #

• Django
• React
• Git

Forking workflow #

This is a fundamentally different approach from the ones mentioned above. The user forks the official repository, creating their own copy of the entire repository. The developer then proceeds to link the official repository with their own, this lets them keep their repository up to date with the official repository. When the developer is done making their changes, they create a pull request to the official repository. The maintainer then proceeds to merge the developer’s changes after ensuring they do not break anything (this is often automated😉).

Pros #

• It’s very secure- the developers do not make their changes directly on the official repository.
• Other developers can easily comment on your changes since you create a pull request.

Cons #

• It has a somewhat steep learning curve- some steps need you to be familiar with some git commands like linking your local repo to track the official repo.

Real-world projects #

Most open-source projects use this workflow. You’ll notice that this workflow is often used with other workflows like the feature workflow.

• Python
• Linux Kernel
• Node.js

Conclusion #

In summary ladies and gents, from observation, it is possible to work on projects without any of these. However, it is often safer to incorporate a workflow for better structure and collaboration. You will thank yourself for choosing to use a workflow when you find yourself trying to find the commit that broke your production build. This is because workflows often lead to a cleaner commit history. That’s all from me, do let me know if you have any questions or would like me to discuss more workflows🙂.