GDG on Campus CVR College of Engineering

Version control is a core component of modern software engineering. It helps teams track changes, collaborate without overwriting each other’s code, and maintain a stable application. In this blog, we'll understand the basic idea behind Git workflows and explore how real-world teams use them.

Version Control System Architecture. Source: FAUN.dev() 🐾

What problem are we solving?

Imagine you just started learning Git. You know the basics:

bash

git add .
git commit -m "fix bug"
git push
git pull

When you are building a personal project alone, this is usually enough. But one day, you join a company with 10, 50, or 100 other developers all working on the exact same codebase.

If everyone just pushes their changes directly to the main server whenever they want, disaster strikes. Developers will overwrite each other's work, unfinished features will accidentally get shipped to users, and when a critical bug crashes the production server, nobody will know which commit caused it or how to safely roll it back.

A Git workflow solves this problem. It is simply a strategy and a set of rules for organizing branches and managing changes.

Didn't understand the problem?

Think of a Git repository as a massive city road system, and the developers are the cars.

When it’s just you driving in a small town, you don't need traffic lights. But as the city grows and hundreds of cars are on the road, driving wherever you want leads to crashes. A Git workflow acts as the traffic lights, lanes, and rules of the road. By giving everyone clear rules on when to merge and where to branch, everyone reaches their destination (shipping the feature) safely without crashing the system.

The Three Major Git Workflows

Different teams build and release software differently, so there isn't one "perfect" workflow. Instead, there are three industry-standard strategies.

1. Git Flow (The Strict approach)

Git Flow is a highly structured workflow. It is designed for large enterprise projects that have scheduled, versioned releases (like V1.0, V1.1, V2.0) rather than updating the app every single day.

It relies on strict branch naming:

main (Contains only stable production code)
develop (The active integration branch for the next release)
feature/* (New features developers are building)
release/* (Preparing for the next production launch)
hotfix/* (Emergency fixes for production bugs)

How it works:

You never commit directly to main or develop. If you're building a login screen, you create a branch from develop called feature/login.

The standard Git Flow branching model. Source: nvie.com

Once all features are done, you merge them into develop, create a release branch to test it, and finally merge it into main to deploy to users.

The Hotfix: If a critical bug hits production, you don't want to deploy develop because it has unfinished code. Instead, you create a hotfix/bug-name branch directly off main, fix it, and merge it back into both main and develop.

2. GitHub Flow (The Agile approach)

Git Flow can be too slow and complex for modern startups and SaaS web apps. GitHub Flow is much simpler: there is only one permanent branch, main.

How it works:

plain

main ➔ feature branch ➔ Pull Request ➔ Review ➔ Merge ➔ Deploy

Branch directly off main.
Write your code and open a Pull Request (PR).
Your teammates review the PR, suggest improvements, and automated tests run.
Once approved, it merges into main and is deployed immediately.

This workflow is incredibly fast and perfect for continuous deployment, but it requires you to protect your main branch by enforcing rules (like requiring passing tests before merging).

GitHub Flow naturally pairs with CI/CD pipelines. Source: GitHub

Here is an example of a GitHub Actions .yml file that ensures code is tested before it can be merged:

yaml

name: Node.js CI

# This action runs every time a Pull Request is opened against the main branch.
on:
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18.x'
        
    - name: Install dependencies
      run: npm ci
      
    # If these tests fail, GitHub blocks the Pull Request from merging!
    - name: Run automated tests
      run: npm test

3. Trunk-Based Development (The High-Speed approach)

This is the workflow used by hyper-fast companies like Google. Instead of long-lived feature branches that sit isolated for weeks, everyone integrates their code into one shared branch (the main or trunk) multiple times every single day.

But how do you merge a half-finished checkout page into the live application without users seeing it?

Feature Flags:

Instead of hiding unfinished code in separate Git branches, Trunk-Based Development hides code using logic.

javascript

if (featureFlags.enableNewCheckout) {
    renderNewCheckout();
} else {
    renderLegacyCheckout();
}

The code exists in production, but users don't see it until you flip the switch on your server. This separates deployment (putting code on a server) from release (letting users see it), giving teams enormous flexibility and eliminating painful merge conflicts.

Managing releases in Trunk-Based Development using Feature Flags. Source: Harness Developer Hub

The Role of AI in Workflows

Modern development teams are also integrating AI into these workflows to speed things up:

AI Pull Request Summaries: Instead of manually typing out everything you changed, AI tools automatically read your commits and generate detailed PR descriptions.
AI Code Reviews: Before a human reviews your PR, AI agents scan the code to catch bugs, security risks, and performance issues. Human reviewers can then just focus on the overall architecture.

See it in action

To make this completely practical, I’ve created a sample repository containing these exact branch structures, mock pull requests, and feature flag examples.

Here's the full source code repository: REPO

Conclusion:

Congratulations! You now understand how professional engineering teams organize their code bases and prevent chaos. While knowing Git commands is great, understanding how to collaborate is what makes you a true software engineer.

If you understand the concepts above, great job! As a next step, you can gradually improve your repository by adding features like:

Setting up Branch Protection Rules on GitHub so no one can push directly to main.
Writing a GitHub Actions CI pipeline that automatically runs tests when a PR is opened.
Integrating a free AI bot (like Codium or Sweep) into your repo to auto-review your Pull Requests.
Setting up a real Feature Flag management tool like PostHog or LaunchDarkly.

You don't have to implement all of these at once. Pick one workflow and try applying it to your next team hackathon or group project.

Happy coding!