Git and GitFlow Practice

git | 2020-02-20

Git in a nutshell

Git is a powerful distributed version control system (VCS) that helps individuals and teams manage changes to code efficiently.

Similar to tools like Subversion (SVN), Team Foundation Server (TFS), and Mercurial,

Git allows you to keep track of changes, collaborate with others, and maintain a complete history of your project.

Git is a distributed version/source control system (VCS). Just like Subversion, Team Foundation Server, Mercurial; each has its pros and cons.

Why Do We Need a Version Control System?

Version control is essential in any development environment—from solo projects to large-scale applications—because it allows:

Multiple developers to work simultaneously without conflicts.
A complete version history, so you can track and revert changes when needed.
Collaboration across teams, even in different time zones.

Understanding the Git Branching Model

Imagine Git as a giant tree, with many branches and millions of leaves. Each part of the tree has a specific role:

Root: The stable, master version of your project.
Central Branch: The main development branch.
Supporting Branches: Feature, release, or hotfix branches that stem from the central branch.
Leaves: Individual tasks or changes made by developers.
Energy: Contributions that feed back into the project—aka, completed and reviewed tasks.

In Git, your central repository typically maintains two main branches throughout the project's lifecycle:

master (or main): Your production-ready branch.
develop: Your staging or main development branch.

Git Branching Strategy

When managing a project with Git, here’s a rule of thumb that simplifies everything:

🧠 One Task = One Branch

This structure promotes cleaner code, easier collaboration, and better traceability. Here's a breakdown of common branch types:

master - Live production-ready code
develop - Latest staging/testing code
feature/* - New features or enhancements
release/* - Preparing for deployment
hotfix/* - Urgent fixes in production

To track project progress and releases, tagging each release (e.g., v1.0.0, v2.0.1) is highly recommended.

This helps identify exactly what went live—and when.

What is a Pull Request?

A Pull Request (PR) is a core Git workflow that allows developers to submit their code for review before it’s merged into the main branch. It’s an essential step for maintaining code quality, readability, and team collaboration.

Here’s how it typically works:

A developer creates a new branch and makes changes.
They submit a Pull Request for that branch.
One or more reviewers go through the code, provide feedback, and approve it.
Once approved, it’s merged into the target branch.

Code Review Golden Rule

🔍 Code should be clean, understandable, and maintainable—because no one wants to inherit messy code.

TL;DR – Git Best Practices in a Nutshell

There’s no “one-size-fits-all” Git strategy. The key is to choose a branching model that fits your team size, workflow, and deployment cycle. Here’s a simple flow to get started:

Git Flow

Whether you're working on a small project or a large-scale system, Git helps you collaborate, experiment, and deploy with confidence.