What Is a Git Workflow? A Simple Guide for Beginners

Git will let a team do almost anything with its branches. It has no opinion on who merges, when, or after whose approval, and that silence is where most of the arguments start.

Nearly everyone is stuck with the same gap, since 96.65% of professional developers use Git (Stack Overflow Developer Survey, 2022). Most teams settle it by adopting a named model: centralized, feature branch, Gitflow, GitHub flow, GitLab flow, trunk-based development or forking.

Which one a team picks decides how quickly a merged change reaches users and how many merge conflicts pile up on the way.

What Is a Git Workflow?

Ask a team how it uses Git and the real answer is a branching and collaboration convention. It covers which branches exist, how changes reach the main branch and who reviews them.

Git doesn’t prescribe any of it. Atlassian’s tutorials say as much: Git is flexible by design, so the process comes from the team, not the tool.

Linus Torvalds built Git for Linux kernel development. Pro Git, the project’s own book, already treats shared work as something with competing answers. It describes a centralized workflow and an integration-manager workflow, then adds a dictator and lieutenants workflow for the biggest projects.

What a Git workflow standardizes

A workflow settles which branch each change starts from, and where finished work lands and by which method. It also names who approves, which automated checks have to pass, and how merged code gets to users. All of that gets written down once so nobody renegotiates it on every change.

The payoff is predictability. Parallel work reaches the shared codebase in a known order, and the main branch stays releasable.

Teams that already depend on version control still need this layer. The tool records history, but it says nothing about who merges what, or when.

What a Git workflow is not

The local cycle of editing in the working directory, staging, committing and pushing sometimes gets the same name. W3Schools does it, and so do a few other tutorials. Every team runs that cycle identically, so it can’t tell one workflow from another.

Then there’s the GitHub Actions meaning. A GitHub Actions workflow is a YAML file under .github/workflows that runs jobs when repository events fire (GitHub Docs).

A Git workflow often triggers those jobs, but the two are separate things.

How a Change Moves Through a Git Workflow

Every change goes from branch to commit to review to merge to release, and the workflow decides what each stage demands. That might be an approval count, a develop branch, a release branch, or a rule about which stage triggers deployment.

1. Branch from the main branch and give the branch a short, descriptive name.
2. Commit locally, then push the branch to the remote repository.
3. Open a pull request so reviewers are requested and automated checks start.
4. Merge into main once the required approvals and checks pass.
5. Deploy from main, or tag a release, depending on the team’s release path.

Branching is the cheap step. Even a small fix gets its own branch, and this guide to creating a new branch in Git covers the command.

GitHub runs this loop for its own site policy, documentation and roadmap, according to GitHub Docs.

Review is where delay builds up. The automated half runs through continuous integration, so every push triggers tests and a failing run blocks the merge.

The other stall is human. A pull request sits waiting for a reviewer, and nothing moves until someone acts. Honestly, this is the stage most teams underestimate.

Variants add stages without changing the loop. Gitflow inserts a develop branch ahead of main, and release-based teams add a release branch before deployment.

Branch Types and How Long They Live

Main, develop, feature, release and hotfix branches show up across most Git workflows, though only main appears in all of them. What really separates one workflow from another is how long its branches live.

Azure Repos guidance points out that Git branches are inexpensive to create and maintain. That is the reason it tells teams to give even small fixes their own.

Branch naming convention

GitHub Docs recommends short, descriptive names so collaborators see ongoing work at a glance. Its examples are increase-test-timeout and add-code-of-conduct.

Gitflow teams usually add prefixes (feature/, release/, hotfix/). At Microsoft, repositories with several hundred developers use a naming convention for server branches to limit confusion and branch proliferation, per the Azure DevOps documentation.

Branch limits from DORA research

DORA, the research program behind the DORA metrics, publishes concrete limits for trunk-based development. A repository should have three or fewer active branches, and work merges into trunk at least once a day. A branch typically lives no more than a few hours, against days or weeks for a classic feature branch. Once releases happen several times a day, release branches aren’t required.

DORA’s own pages do not word the limits identically. As of October 2026, the trunk-based development page says three or fewer active branches, while the continuous delivery page says fewer than three and describes branch age as under a day.

Treat the numbers as a direction, not a hard line. Both pages agree on the substance, which is few branches, merged fast.

Merge, Squash or Rebase: How Branches Rejoin Main

A branch can rejoin main through a merge commit, a squash merge, or a rebase followed by a fast-forward. Each leaves different history behind and keeps a different amount of the branch’s own commit trail.

Merge commit

A merge commit keeps every commit from the branch and rewrites nothing, so it is safe on shared branches. Branch boundaries stay visible in the log.

The cost is nonlinear history. Merge commits add noise when you’re scanning the log or bisecting.

GitLab’s docs describe this as the default merge method: it always creates a separate merge commit, even when squashing.

Squash and merge

GitLab’s documentation says squashing combines a branch’s commits into one meaningful commit, which keeps history clean and makes changes easier to track or revert.

Main ends up with one readable commit per branch, and messy work-in-progress commits disappear. The downside is lost detail. A bisect lands on the whole branch, and the original commits survive only on the branch itself.

Rebase and fast-forward

Rebasing gives you linear history with no merge commits, so the log reads like a straight line. The catch is that it abandons existing commits and creates new, similar ones, and each replayed commit can hit its own conflict.

Pro Git’s rule is short: never rebase commits that others may have built on. Rebase local work before pushing, and leave pushed history alone.

GitLab exposes the choice as a project setting with three options: merge commit, merge commit with semi-linear history, and fast-forward merge. With fast-forward only, a branch that cannot be fast-forwarded must be rebased first.

Where merge conflicts come from

Conflicts appear when two branches change the same lines. The longer a branch lives, the further it drifts, which is why DORA ties small, frequent merges to less complex merging.

When one lands, resolving merge conflicts in Git comes down to editing the marked files, staging them, and finishing the merge or rebase.

How Pull Requests and Branch Protection Enforce Review

A pull request proposes merging one branch into another and gives others a chance to review the change first. GitLab calls the same gate a merge request, while GitHub, Bitbucket and Azure DevOps say pull request.

Branch protection rules

GitHub’s branch protection rules turn the review step from a habit into a requirement. They can demand a pull request before anything merges into the protected branch. On top of that, they can require approving reviews from a set number of reviewers and status checks that pass before merging.

A required check must finish as successful, skipped or neutral before the merge is allowed. A strict setting also forces the branch to be up to date with its base branch, and a loose one does not (GitHub Docs).

The human half of the gate is the code review process. Approving a pull request on GitHub is one click, but a protection rule can dismiss that approval as stale when new commits arrive.

Code owners and required reviewers

A CODEOWNERS file maps paths to people or teams. When a pull request touches their files, GitHub requests their review automatically, except on draft pull requests.

Once “Require review from Code Owners” is on, an approval from any single owner satisfies the rule.

GitLab offers the same pairing: protect the target branch, then require Code Owner approval. Its docs carry a warning, though. Users allowed to push to a protected branch can skip merge request approval rules, Code Owners included.

Microsoft’s release flow routes every topic branch through a pull request that must satisfy branch policies, which keeps main buildable at all times.

Review has a cost, and DORA’s reference guide names a heavy-handed or asynchronous review process as a common pitfall of trunk-based development. A gate that waits days for a reviewer defeats the short branch it was meant to protect.

How Releases and Hotfixes Work

A release can go out straight from main, from a release branch, or as a tag at a chosen commit. Hotfixes split along the same lines, because the release path decides where an urgent fix has to land.

Deploying straight from main

GitHub flow assumes every merged branch can go to production, as GitLab’s documentation describes it.

GitLab flow adds a production branch for teams that cannot work that way. A release is a merge of main into production, which skips the releasing, tagging and merging overhead of Gitflow, and checking out the production branch shows what is live.

Release branches

Under the trunk model, a release branch starts as a snapshot of a chosen point on trunk, which need not be the latest commit. No one commits to it directly. Fixes land on trunk first and get copied over with git cherry-pick, and the branch is deleted later, never merged back.

That is the model trunkbaseddevelopment.com describes. Gitflow differs: its release branch merges into both main and develop, per Atlassian’s tutorial.

Tags and version numbers

A tag pins a release to one commit. Creating a git tag at the merge marks the exact code that shipped.

The number on that tag often follows semantic versioning, as the SemVer 2.0.0 specification defines it. MAJOR covers incompatible API changes, MINOR covers backward-compatible functionality, and PATCH covers backward-compatible bug fixes.

Conventional Commits maps onto that scheme. A fix commit translates to PATCH, a feat commit to MINOR, and a BREAKING CHANGE footer to MAJOR (Conventional Commits 1.0.0).

A released version is immutable. The SemVer spec requires any modification to ship as a new version.

Where a hotfix starts and where it lands

Gitflow’s double merge is the step teams forget. A fix that skips develop comes back as a regression in the next release.

Git Workflow Types Compared

Most teams end up on centralized, feature branch, Gitflow, GitHub flow, GitLab flow, trunk-based development or forking. They differ in how many long-lived branches they keep and how quickly a merged change can reach users.

Centralized and feature branch workflows

The centralized workflow runs on main alone. Atlassian places it with teams migrating from SVN and with smaller teams, and notes that it defines no pull request or forking pattern.

Git refuses a push when local commits diverge from the central repository, so the second developer to push has to integrate first.

The feature branch workflow adds one branch per change and a review before merge. Gitflow, GitHub flow and GitLab flow all build on it.

Gitflow

Vincent Driessen published Gitflow in 2010.

In a note dated March 5, 2020, he wrote that web apps are typically delivered continuously, rarely rolled back and run as a single version. For teams in that position he advised something simpler, such as GitHub flow.

Atlassian goes further. Its tutorial labels Gitflow a legacy workflow that is hard to run with CI/CD, and keeps the page for historical reasons.

GitHub flow and GitLab flow

GitHub flow is short. Branch off main, open a pull request, deploy after the merge. GitHub Docs describes it as lightweight and built for teams that deploy regularly.

GitLab flow keeps feature branches and adds an environment ladder. Changes are promoted one environment branch at a time, for example from main into pre-production, and merging pre-production into production goes live.

Everyone branches from main, so GitLab’s guide stresses that main must never break.

Trunk-based development

Google runs one trunk. Most engineers work at its head, and commits land in a single serial order, according to the Communications of the ACM paper on Google’s repository.

Trunk-based development at ordinary scale looks different. Unfinished work lands behind a feature flag that ships switched off, per trunkbaseddevelopment.com.

The model gives up hiding unfinished work on a branch, so flags and fast tests take over that job (Unleash documentation).

Forking workflow

Every contributor gets a personal server-side repository, which means each person works with two remotes, the official repository and their own fork. Only the maintainer pushes to the official one.

Atlassian’s tutorial adds that “official” is only a convention. Pro Git describes a larger variant, the dictator and lieutenants workflow, and calls it uncommon outside very big or hierarchical projects.

Which Git Workflow Fits Your Team?

Match the workflow to release cadence first, team size second and CI maturity third. Frequent deployment points to GitHub flow or trunk-based development, while several supported versions in production point to Gitflow or release branches.

• A team deploying several times a week should look at GitHub flow, or trunk-based development once CI runs fast.
• If several versions are supported at once, Gitflow or trunk with release branches fits better.
• Staged environments with sign-off suit GitLab flow.
• Contributors without write access call for the forking workflow.
• Two to five people on one product do fine with the feature branch workflow and a protected main.

The default for most small teams is GitHub flow. Gitflow earns its extra branches only when the product ships numbered versions.

Where sources disagree on Gitflow

Atlassian calls Gitflow a legacy workflow. Driessen, who created it, still frames it as a model for version-based software and advises against it only for continuous delivery.

The two positions answer different questions. Atlassian judges Gitflow against continuous deployment, where long-lived branches slow every change, while Driessen scopes it to teams that ship numbered versions.

How to Set Up a Git Workflow in a Repository

Start with GitHub flow and add structure only when release needs demand it.

1. Name the default branch main and agree that it stays deployable.
2. Protect it with required pull requests, approving reviews and passing status checks.
3. Set one default merge method in repository settings so every pull request ends the same way.
4. Name branches by type and topic (feature/, fix/) and delete them after merging.
5. Pick a commit format. Conventional Commits uses a type, an optional scope and a description, such as fix(parser): handle empty input.
6. Write the rules into the repository, in a CONTRIBUTING file or a README section.

The spec mandates only feat and fix. The @commitlint/config-conventional preset adds build, chore, ci, docs, style, refactor, perf, revert and test.

Merged branches pile up fast, and a short guide on how to delete a branch in Git covers the cleanup commands.

Review the setup after a month of real use. If pull requests sit for days, loosen the gate before people start working around it.

When a Git Workflow Breaks Down

Each workflow fails under a specific condition, and the condition is usually visible well before the damage is.

Long-lived branches are the most common one. GitLab’s workflow guide describes many long-running branches that each hold part of the changes, and Atlassian ties long-lived feature branches to harder merges and conflicting updates.

Gitflow under CI/CD is another. Atlassian calls it challenging to run, and Driessen’s 2020 note advises against forcing it onto continuously delivered software.

Environment branches go wrong when someone skips a step. GitLab flow promotes changes one environment branch at a time, for example main into pre-production and pre-production into production, so a fix committed straight to production breaks the order.

Scheduled releases cause drift. AWS Prescriptive Guidance describes production and development matching only on release day and diverging again right after, which leaves developers many features ahead of production and forces a readjustment whenever a production issue appears.

Trunk-based development fails differently. It works only with fast automated tests and feature flagging.

A flag lets unfinished commits enter trunk while staying inert in production, according to trunkbaseddevelopment.com. Without one, the team has to hold work back until it is complete, and the short branch turns long.

Code freezes are the last warning sign. DORA describes trunk-based teams as rarely or never needing code lock periods, so a freeze before every release means the workflow behaves like Gitflow, whatever it is called.

Git Workflow FAQ

What are the three states of files in Git?

Modified, staged and committed. A modified file has changed in the working directory, a staged file is marked for the next commit, and a committed file sits in the local repository.

These states belong to the local cycle, not to a team’s branching convention.

Does a solo developer need a Git workflow?

Yes, a light one. A protected main branch, short feature branches and descriptive commit messages keep history traceable and make a bad change easy to revert.

Review gates and release branches add nothing without a second person.

Can a team change Git workflows later?

Yes. A workflow is a convention, not a tool, so a team can switch when its release cadence or size changes, for example from Gitflow to trunk-based development.

The repository stays the same. Only the branch rules and protection settings change.

Moving a Team to a Different Git Workflow

The safest way to change workflows is to migrate one repository first and let open branches finish under the old rules. The new convention then spreads one repository at a time.

Order matters here, because each step removes a risk the next one would inherit. Long-lived branches get merged or closed first, then the new rules are piloted on a single repository. Branch protection and CI are updated only after that, right before the wider rollout.

Open branches go first because they carry the old rules and the oldest conflicts. Protection settings go last because they lock the convention in.

The price is a transition period in which contributors work under two sets of rules. A reference of Git commands helps newcomers through that stretch.

This sequence holds as of October 2026. A host that changes its default merge or protection settings would alter the final step.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026
• PostgreSQL Cheat Sheet - October 2, 2026
• How to Repair a Corrupt SQL Server Database Without Any Data Loss - October 2, 2026