Practical Git Flow: How to Manage Branches to Avoid Team Conflicts – ITFROMZERO

Table of Contents

Teamwork Without a Process is a Recipe for Disaster

When I first started working, I thought Git was just about add, commit, and push. Things fell apart when the project grew to over 10 people, with everyone modifying the cart logic and pushing directly to master. The result was conflicts as long as a grocery list. My code worked fine locally but crashed on Production due to missing files. Git Flow was born to solve this chaos, creating a hard line between development code and production-ready code.

Quick Start: Implement Git Flow in 5 Minutes

Don’t waste time reading thick documentation. Install the git-flow tool immediately. It’s essentially a wrapper of “shortcuts” that helps you perform complex workflows with just a few concise keywords, instead of typing 4-5 pure Git commands.

1. Fast Installation

# macOS
brew install git-flow-avh

# Ubuntu/Debian
sudo apt-get install git-flow

# Windows
# Usually pre-installed in Git Bash; if not, download git-flow-avh.

2. Initialize the Project

Open your terminal in the project root and type:

git flow init

Git will then ask for branch names (main, develop, feature…). My advice: Just press Enter to accept all defaults to make it easier for your team and international partners to collaborate.

3. Start a New Feature

git flow feature start login-facebook

This command automatically branches off from develop and switches you to it immediately. Once you’re done coding, just type:

git flow feature finish login-facebook

It will automatically merge into develop and clean up the created branch. Completely hands-free!

Decoding the 5 “Backbone” Branches in Git Flow

This workflow divides the repo into 2 permanent main branches and 3 types of temporary branches that are deleted after their tasks are finished.

1. Main Branches (Main & Develop)

Main: Contains the cleanest code, strictly tested. Only push code here when you’re ready to release to customers. Never commit directly to Main.
Develop: This is the “laboratory”. All new features flow here for peer testing before being bundled.

2. Supporting Branches (Feature, Release, Hotfix)

Feature: Every Jira task should be its own branch. An absolute rule: 1 task = 1 branch.
Release: When the develop branch has accumulated enough features for version 2.0, you fork this branch. This stage is strictly for fixing minor UI bugs or typos; never add new features here.
Hotfix: Imagine the checkout page hitting a 500 error on New Year’s Eve. You’ll fork a Hotfix branch from main, fix it, and merge back into both main and develop to put out the fire immediately.

Advanced: Combining Git Flow with Pull Requests (PR)

In practice at large companies, we rarely use the finish command locally. Instead, we combine it with Code Review workflows on GitHub/GitLab:

Create branch using git flow feature start my-task.
Push the branch to the server: git push origin feature/my-task.
Open a Pull Request on the web for colleagues to review the code.
After approval, merge directly on the web, then pull the new code to your local machine.

Pro Tip: Why Use –no-ff?

If you merge manually without the --no-ff (no fast-forward) flag, Git will collapse commits into a straight line. This makes the repo history look extremely cluttered. With --no-ff, Git creates a clear merge commit node. Looking at the graph, you’ll immediately know where a feature started and ended, making it very easy to trace if bugs arise later.

Real-world Tips for Team Leaders

To prevent Git Flow from becoming a burden, apply these 3 rules to your team:

1. Name Branches by Ticket ID

Don’t use names like feature/urgent-bug-fix. Use the format: branch-type/ticket-id-description. For example: feature/PROJ-123-api-login or hotfix/PROJ-456-fix-crash-ios.

2. Automate Pipelines (CI/CD)

Set it up so that whenever code is pushed to develop, the system automatically deploys to the Staging environment for Testers. When code is merged into main and tagged as v1.1, the system automatically pushes to Production. This reduces 90% of silly manual errors.

3. Regular Cleanup

Many have the habit of leaving dozens of old branches gathering dust on their machines. At the end of each Sprint (usually 2 weeks), spend 5 minutes deleting merged branches. Your computer runs faster, and you won’t get dizzy looking for code.

Conclusion

I was once in a situation where my boss demanded an urgent fix for data loss on Production while I was in the middle of a massive unfinished feature. Thanks to Git Flow, it took me only 2 minutes to stash my work, jump to main, create a hotfix branch, fix the bug, and deploy within exactly 15 minutes. Everything went smoothly.

If you’re working on a project alone, Git Flow might seem a bit cumbersome. But with a team of 2 or more, applying this process from day one will save you dozens of hours spent resolving conflicts and arguing over who overwrote whose code.

Don’t hesitate to try it. Create a dummy repo, practice typing init, start, and finish a few times to get the hang of it before applying it to your company’s real projects!