Chapters
Chapters

Chapters

Hide chapters

Advanced Git

Third Edition · Git 2.50 · Console

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Advanced Git

Section 1: 7 chapters
Show chapters Hide chapters

Section II: Git Workflows

Section 2: 5 chapters
Show chapters Hide chapters

8. Centralized Workflow
Written by Jawwad Ahmad

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

A centralized workflow is the simplest way to start with Git. With this workflow, you work directly on the main branch instead of in separate feature branches.

Creating branches in Git is extremely easy, so you should only skip creating branches when they would cause extra overhead that isn’t necessary.

In this chapter, you’ll learn about scenarios where the centralized workflow is a good fit. You’ll also learn how to handle common situations that arise when multiple developers are committing directly to the main branch.

When to use the centralized workflow

One of the primary reasons to first commit and push your code to a branch is to allow other developers to review your code before you push it to your main branch. If the code doesn’t need to be reviewed, the overhead of creating and pushing a separate branch is unnecessary. That’s where the centralized workflow is a great fit.

Here are a few scenarios where a code review may not be necessary.

1. When working alone

If you’re the sole developer on a project, you don’t need the overhead of creating branches since there are no other developers to review your code.

2. When working on a small team

If you’re part of a small team where each team member has a specialized area of knowledge, a centralized workflow is a good choice. For example, if one developer works on backend code using one programming language and another works on front-end code in a different language, it’s not always useful or practical for those team members to review code outside of their area of expertise.

Gyudq siug koks zey-igeqxomwedx isvokbuzo eg goqa uyrokhvos
Gxufd muaq zekt ded-ajisrotqupw aqbuvxeki or ribo ertajygoc

3. When optimizing for development speed

Code reviews are a great way to improve the code’s quality before pushing it to the central repository, but every code review has some overhead.

Zusfxixuyuj Wujqjyoz nv Tsevrkewm Caqjcmuf
Zazptonadep Lelvmwon jn Vcogclimr Qujxkzil

4. When working on a new project

The need for expediency is often stronger when working on a new project with tight deadlines. In this case, the inconvenience of waiting for a code review may be especially high.

Chud sias joadty hefi! Huwg kmov kq ycu 1pc!
Hjes xias liamlg fova! Weqj nrad qd dgu 8gj!

Centralized workflow best practices

Here are some best practices you can adopt to make using the centralized workflow easier. These are especially important when working in teams where multiple developers are committing to main.

Rebase early and often

When using the centralized workflow in a team, you often have to rebase before pushing to main to avoid merge commits.

Avoid merge commits

At times, your local main branch may diverge from the remote origin/main branch. For example, when you have local commits that you haven’t pushed yet, and the remote origin/main has newer commits pushed by others.

Getting started

To simulate working on a team, you’ll play the role of two developers, Alex and Beth!

State of the project

The remote origin repository, checklists.git, contains four commits, which we’ll refer to as A1, B1, A2 and B2 instead of with their commit hashes. Alex’s and Beth’s projects also have local commits that have not yet been pushed to the remote. Alex has one additional commit, A3, and Beth has two, B3 and B4.

Hifihiovsces cozcuux unupil/meim abn Odos afl Gobp’n toin cnozxcir
Pigamaaxqmon jofjoib adazav/yoaw ozh Ohap uzp Bizw’p yeoj pgevlkex

Pushing Beth’s commits to main

Switch to the beth/checklists tab in your terminal and run git status. It should show the following to verify that it’s ahead of origin/main by two commits:

Qesimoamkviy maxzaal ativop/kuar elv voxim jaaz dtikztat ayget Dely’n wixt
Matipiuqjlib cafquis ayubec/ceoh alx jaric zoev lcebxcir ivquw Fezl’x vokc

Pushing Alex’s commit to main

Switch to your alex/checklists tab and run git status:

Wafiaz kiznayitjuvuir uk rqu hfubeoig wav guw --asahosa --swuqz --uwv rijjejx
Dayeeq viqdopondiniaw et yvu qxebauek bon veq --omexuco --rfesv --ith fozlads

Creating a merge commit

When you use the --no-rebase option with git pull, it actually runs two two separate commands: git fetch and git merge origin/main.

Aborting a merge commit

Take a look at the last line of the commit message template. It says:

Undoing a merge commit

Run git pull --no-rebase again to trigger the merge. When Vim opens, type :wq to accept the default message and commit the merge.

Rebasing the merge commit

Another strategy you can adopt is to rebase your main branch, which now contains the merge commit, onto origin/main. This applies A3 and the merge commit on top of B4. Since origin/main already has B3 and B4, i.e., the contents of the merge commit, this removes the merge commit entirely.

Using git pull --rebase

You previously learned that git pull --no-rebase is the combination of two separate commands: git fetch, and git merge origin/main.

Setting up automatic rebase

You can also set up git pull so that it using --rebase by default. Recall that if you ran git pull and didn’t have a strategy configured to resolve divergent branches, you would have seen the following:

Key points

  • The centralized workflow is a good fit when working alone or on small teams, when optimizing for speed or when working on a new, unpublished project.
  • You can still create branches for in-progress code or for ad-hoc code reviews.
  • Rebase frequently to incorporate upstream changes and resolve conflicts sooner.
  • Prefer git pull --rebase instead of git pull --no-rebase to avoid creating merge commits.
  • Set the pull.rebase option to true in your Git config to automatically rebase when pulling.
7. The Many Faces of Undo
9. Feature Branch Workflow
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now