Git Workflows — How the Friends Work Together

Knowing individual commands is like knowing how to hold a pen. Knowing a workflow is knowing how to write a whole report with five people and never lose a page. Here are the three routines the Campus Library team follows.

1 · The Daily Save Workflow — Everyone's Habit

This is the rhythm every single day, even when working alone. If you only remember one workflow, remember this one:

1. git status        →  "What changed since yesterday?"
2. git add .         →  "Put my new pages on the desk."
3. git commit -m ""  →  "Glue them into MY notebook."
4. git pull          →  "Get the newest pages from the library."
5. git push          →  "Send my pages to the library."

The full daily habit

git status
git add .
git commit -m "Add today's changes"
git pull
git push

:::warning Why pull before push? Five friends are writing. If you push without pulling, you might send pages built on an old copy — the library may refuse them. git pull first keeps everyone in sync and prevents most conflicts before they happen. :::

2 · The Feature Branch Workflow — Experiment Without Fear

Arjun needs two weeks to build "order tracking". He does not want to break the working app that his friends keep reading. So he takes his own notebook copy:

Create and enter a branch for the feature

git switch -c feature-order-tracking

He commits his work on this branch all week. The main notebook stays safe:

Work on the branch

git add .
git commit -m "Add order status page"
git commit -m "Connect tracking API"

When the feature is finished and tested, he brings it back into main:

Merge the finished feature into main

git switch main
git merge feature-order-tracking

Already up to date!        ← if the feature was merged elsewhere
Merge made by the 'ort' strategy.   ← feature merged successfully

:::tip Remember Rule of thumb: one branch per feature. If a feature is broken, the whole team is not affected — only that one branch. :::

3 · GitHub Flow — The Team's Official Routine

When the team hosts the central library on GitHub, they follow a simple, famous routine called GitHub Flow:

main                ← always deployable, always working
   │
   └─ 1. Create a branch from main      git switch -c feature-name
   │  2. Commit your work               git add . && git commit -m "..."
   │  3. Push your branch               git push -u origin feature-name
   │  4. Open a Pull Request (PR)       "please review my pages on GitHub"
   │  5. Merge the PR into main         reviewer clicks Merge
   │
   └─ back to 1 — start the next feature

• Pull Request = a polite request: "Reviewers, please read my pages before they join the official notebook." It is where teammates discuss, comment, and approve.
• main stays green — nobody writes directly to it; everything arrives through a review.

:::tip Remember GitHub Flow works because main is sacred: you can always run the app from main and trust it. All risk lives on short-lived branches. :::

4 · Merge vs Rebase — Straight Line or Fork in the Road?

Both commands combine your branch with main, but they tell the story of the notebook differently.

git merge

What happens: Git records a special merge commit — the two histories join like two roads meeting.

    A---B---C  feature-login
   /         \
--o---o---o---M  main

• Preserves the real story: "these pages were written at the same time by different people."
• Safe on shared branches — it never rewrites existing commits.
• History shows a fork and a join (a few "spaghetti lines" in git log --graph).

Merge the feature into main

git switch main
git merge feature-login

git rebase

What happens: Git picks up your commits and replays them on top of the newest main — as if you started your work just now. No merge commit.

Before:          After:
    A---B        feature-login
   /                       A'---B'  feature-login
--o---o---o  main         /
                      --o---o---o  main

• History is a beautiful straight line — easier to read.
• Rewrites your commit hashes (A becomes A'), so it must never be used on commits others already pulled.
• Perfect for cleaning up a branch right before merging it into main.

Replay feature commits on top of main

git switch feature-login
git rebase main

The Rule of Thumb

Choose like the librarian would

• Rebase to keep your private, not-yet-pushed branch clean and straight.
• Merge when the branch has been shared or merged into the official history — never rewrite what others already have.
• In a team using Pull Requests, merge is the default; rebase is the polish before you ask for review.

:::warning Never rebase shared commits If someone else already pulled your commits, rebasing rewrites them into different commits — that person's copy and the library's copy will disagree forever. Rewriting public history is how teams lose an afternoon. :::

You've seen the theory. Now let's actually do it — open Hands-on Exercises and build Campus Library step by step.