App Development & Staff Augmentation Company India, USA

Centralized Workflow

The centralized workflow is the simplest Git collaboration model. All developers work on a single branch — usually main — and push their commits directly to the shared remote. It mirrors the model of older version control systems like SVN, making it a natural starting point for teams migrating from SVN or for very small teams that do not need the overhead of branching strategies.

How it works

Centralized workflow — everyone shares one branch

Text

Remote:  origin/main
              A ── B ── C ── D ── E ── F
                            ↑         ↑
                        Alice       Bob
                        pushed C   pushed F

Local (Alice):
  main:  A ── B ── C

Local (Bob):
  main:  A ── B ── D ── E ── F

Everyone pulls from and pushes to the same branch.
There are no feature branches, no PRs — just direct commits.

Who uses it

Solo developers — no collaboration needed; one branch is perfectly sufficient.
Tiny teams (2–3 people) — when overhead of branching is not worth it.
SVN migration teams — preserves the familiar "commit to trunk" mental model during transition.
Simple scripting projects — configuration repos, dotfiles, scripts where branching adds zero value.
Learning environments — teaching Git basics without introducing branching complexity.

Step-by-step daily flow

Start the day: pull the latest changes from origin/main.
Make your edits in the working directory.
Stage and commit your changes locally.
Pull again before pushing to pick up any new changes from teammates.
Resolve any conflicts that arise.
Push your commits to origin/main.

Alice's daily workflow

Bash

# 1. Start the day — get latest changes
git pull origin main
# Already up to date.

# 2. Do your work
vim src/feature.ts

# 3. Stage and commit
git add src/feature.ts
git commit -m "feat: implement user search"

# 4. Pull again before pushing (someone may have pushed while you worked)
git pull origin main
# (if conflicts arise, resolve them)

# 5. If a merge conflict occurred, fix it:
# Edit the conflicting file, then:
git add src/feature.ts
git commit -m "Merge branch 'main' of github.com:team/project"

# 6. Push to shared main
git push origin main
# To github.com:team/project.git
#    abc1234..7e4f1a2  main -> main

Handling conflicts in centralized workflow

Because everyone pushes to the same branch, conflicts are the most common pain point. When two developers edit the same file, the second person to push will face a rejection.

What happens when two developers edit the same file

Bash

# Bob tries to push his commit:
git push origin main
# To github.com:team/project.git
#  ! [rejected]        main -> main (fetch first)
# error: failed to push some refs to 'github.com:team/project.git'
# hint: Updates were rejected because the remote contains work that you do
# not have locally.

# Bob must pull first:
git pull origin main
# Auto-merging src/app.ts
# CONFLICT (content): Merge conflict in src/app.ts
# Automatic merge failed; fix conflicts and then commit the result.

# Bob opens the file and resolves the conflict markers:
# <<<<<<< HEAD
# Bob's code
# =======
# Alice's code
# >>>>>>> abc1234 (origin/main)

git add src/app.ts
git commit -m "Merge: resolve conflict in app.ts"
git push origin main

Use --rebase instead of merge for a cleaner history

Replace `git pull origin main` with `git pull --rebase origin main` to replay your commits on top of the remote's commits instead of creating a merge commit. This keeps the history linear and easier to read.

Using rebase instead of merge on pull

Linear history with pull --rebase

Bash

# Without rebase — creates a merge commit:
git pull origin main
# Merge branch 'main' of github.com:team/project  ← ugly extra commit

# With rebase — replays your commits on top of the remote:
git pull --rebase origin main
# First, rewinding head to replay your work on top of it...
# Applying: feat: implement user search

# History stays linear:
git log --oneline -5
# 7e4f1a2 feat: implement user search  ← your commit, on top
# abc1234 fix: correct header styling  ← Alice's commit
# 9a8b7c6 feat: add footer links
# ...

# Set this as the default behavior globally:
git config --global pull.rebase true

Problems with the centralized workflow

Direct pushes to main are risky in larger teams

In the centralized workflow, there is no code review gate. Anyone can push broken code directly to `main` at any time. A single bad push can break the build for the entire team.

No isolation — a broken commit immediately affects everyone who pulls.
No code review — there is no natural point to ask a colleague to review your work before it lands.
Risky deployments — if you deploy from main, any pushed commit could end up in production.
Conflict-heavy with larger teams — the more developers push to the same branch, the more frequently conflicts occur.
No parallel experimentation — you cannot safely try a risky refactor without it affecting everyone.
No clear release point — any commit might be a "release" but there is no enforced quality gate.

When centralized works fine

Situation	Works?	Reason
1 developer	Excellent	No conflicts possible
2–3 developers, low overlap	Good	Conflicts are infrequent
Config / infrastructure repos	Good	Changes are infrequent and targeted
4+ developers on same codebase	Poor	Conflicts become frequent
Active feature development	Poor	No isolation for in-progress work
Any deployment pipeline	Poor	Every commit goes straight to deployable branch
Open-source with contributors	Never	External contributors cannot push to main

When to graduate to a different workflow

When you find yourself manually coordinating with teammates to avoid pushing at the same time — switch to Feature Branch Workflow.
When you need code review before merging — switch to Feature Branch or GitHub Flow.
When you want automated CI on proposed changes (not just on main) — switch to Feature Branch Workflow.
When you need to maintain multiple versions in parallel — switch to Git Flow.
When you are deploying multiple times per day — switch to GitHub Flow or Trunk-Based Development.

Adding a minimal safety net to centralized workflow

Even in the simplest centralized setup, you can add a lightweight safety net without adopting a full branching strategy.

Minimal safety practices for centralized workflow

Bash

# 1. Always run tests before pushing
npm test && git push origin main

# 2. Use commit hooks to block bad commits
# .git/hooks/pre-commit:
#!/bin/bash
npm run lint
npm test
# (Git refuses the commit if these fail)

# 3. Enable branch protection on GitHub
# Settings → Branches → Add rule for 'main'
# Require status checks: CI/CD must pass before push

# 4. Use meaningful commit messages
git commit -m "fix: correct null check in user auth (#42)"
# (reference issue numbers for traceability)

# 5. Pull --rebase to keep history clean
git config --global pull.rebase true

Centralized workflow is still valid — just limited

The centralized workflow is not "wrong" — it is just a simple tool that works well within its constraints. Many senior developers run solo projects using a centralized workflow perfectly happily. The key is knowing when you have outgrown it.