Module 8 Lesson 1: Centralized Workflow
·DevOps

Module 8 Lesson 1: Centralized Workflow

Start simple. Learn the Centralized Workflow—the most basic way for teams to collaborate, where everyone works on 'main' and manages conflicts as they arise.

Module 8 Lesson 1: Centralized Workflow

In earlier modules, we focused on commands. Now, we focus on Strategy. A Git Workflow is a set of rules that defines how your team uses Git to build software.

The Centralized Workflow is the simplest possible strategy. It transition users from older systems (like SVN) into the world of Git without overwhelming them with branches.


1. How it Works

In this workflow, there are no branches. There is only one central remote repository and one local development branch (usually main).

The Daily Routine:

  1. Pull: Start your day by downloading your teammates' work: git pull origin main.
  2. Work: Edit your files.
  3. Commit: Save your changes locally: git add . and git commit.
  4. Push: Upload your work: git push origin main.

2. Managing Conflicts

Because everyone is working on the same branch, conflicts are very common. If a teammate pushes a change to main while you are still working, your git push will be rejected.

You must then:

  1. Pull their changes.
  2. Resolve any merge conflicts.
  3. Commit the merge.
  4. Push again.
graph LR
    UserA["Dev A"] -- "Commit & Push" --> Server["Central Server (main)"]
    UserB["Dev B"] -- "Commit & Push" --> Server
    Server -- "Pull" --> UserA
    Server -- "Pull" --> UserB

3. Pros and Cons

Pros

  • Simplicity: Very easy to learn. No need to understand branching or merging strategies.
  • Speed: Great for tiny teams or quick prototypes.

Cons

  • Unstable Main: Because everyone commits to main, it’s very easy for someone to push broken code that stops everyone else from working.
  • Bottlenecks: Resolving conflicts every single time you push becomes exhausting on teams with more than 2-3 people.

Lesson Exercise

Goal: The Collaboration Race (Mental Exercise).

  1. Imagine you and a teammate are both editing the README.md file.
  2. Teammate pushes their change first.
  3. You try to push. What command does the terminal tell you to run?
  4. You run git pull.
  5. What does the README.md file look like now? (Think back to the conflict markers from Module 4).
  6. How do you finish the transaction?

Observation: You'll realize that while simple, this workflow creates a lot of "noise" in your history because every push is interrupted by a pull and a merge.


Summary

In this lesson, we established:

  • The Centralized Workflow uses only the main branch.
  • It is simple but scales poorly.
  • It relies heavily on constant pulls and conflict resolution.

Next Lesson: We’ll learn how professionals solve these problems using Lesson 2: Feature Branch Workflow.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn