Git for Beginners
by Sergey Okinchuk
Chapter 10: Habits That Keep You Out of TroubleCommit Hygiene and Branch Naming
A Day of Git
Topic 42

A Day of Git

Habits

Ten chapters collapse into one loop that you run several times a day. Seen in order, in one place, it is much smaller than the book that taught it.

Starting

The first two commands of the day
git switch main
git pull

Begin from what the project actually is now, not from where you left it yesterday. Someone else may have merged something; you may have merged something yourself through the website. Skipping this is behind most of the confusion people report in their third week.

Working

A branch, then the rhythm from Chapter 2
git switch -c mobile-sightings-layout

# edit, then when one idea is finished:
git status
git add style.css
git diff --staged
git commit -m "Wrap the sightings list on narrow screens"

Branch first, even for a ten-minute change. Then the loop: check where things are, stage what belongs together, read what you are about to record, commit it with a sentence.

Commit whenever a coherent piece works. Several times an hour is normal; two hours with nothing committed usually means you have three things half-done.

Interruption

Something urgent arrives mid-change
git stash push -m "half-finished layout"
git switch main
git pull
git switch -c fix-broken-link
# fix, commit, push, open the pull request

git switch mobile-sightings-layout
git stash pop

Set the work aside, deal with the urgent thing on its own branch, come back. The drawer from Chapter 5 exists for exactly this shape of afternoon.

Finishing

Propose it, then tidy up once it lands
git push -u origin mobile-sightings-layout
# open the pull request, respond to review, merge on GitHub

git switch main
git pull
git branch -d mobile-sightings-layout

Back where you started, with the work landed and the label cleaned up. The next piece of work begins with the same two commands as this morning.

The whole day in six commands

Look at what that transcript actually used: switch, pull, add, commit, push, status. Six commands carried an entire working day.

None of that is simplified for beginners. It is close to what a professional's day looks like, because the rare commands stay rare — you reach for revert or reflog occasionally and look up anything beyond that. Knowing this is worth something on its own: the size of Git is not the size of the job.

One Tuesday on Sandpiper
09:10 — catch upmain is behind by two
→
09:20 — branch and workthree commits · one interruption stashed
→
14:00 — proposepull request and review
→
16:30 — land and tidymerge, pull, delete

What the day never included

No reset. No rebase. No --force. No history rewriting of any kind.

The example was not arranged to avoid them. A normal working day on a normal project does not need any of them, which is why a book that leaves them out can still leave you able to do the job.

Common Confusions
  • "Professionals use dozens of Git commands every day." They use about six and look the rest up. The rare commands stay rare, which is why the deep dive functions as a reference rather than as memory.
  • "Pulling first is optional if nobody else is working on the project." Your own merges through the website count as someone else, and so does your other laptop. Pull anyway; it costs a second.
  • "I should commit once at the end of the day." A day is not one idea, and an uncommitted day is a day with no safety net at all.
  • "Branching for a ten-minute change is overkill." It costs one command and keeps main working. The ten-minute change is also the one most likely to get tangled with the urgent thing that arrives at 11:40.
Why It Matters
  • Seeing the whole loop at once is what turns a book of separate commands into a single habit you can run without thinking.
  • The start-of-day pull is the one habit that prevents the largest share of sync problems people hit in their first month.
  • Knowing that six commands carry the job removes the low-level anxiety that there is some large body of Git you have not learned yet.

Knowledge Check

Why does the day start with git switch main and git pull?

  • So your work starts from what the project is now, not from yesterday
  • Because Git requires a pull before any new branch can be created locally
  • Because uncommitted work from yesterday is discarded unless you pull first
  • Because main is locked overnight and the pull releases it for editing

Which six commands carried the whole working day in this topic?

  • switch, pull, add, commit, push, status
  • init, clone, merge, rebase, reset, push
  • status, diff, log, show, blame, reflog
  • stash, restore, revert, amend, branch, merge

Something urgent arrives while you are mid-change. What does the day's routine do?

  • Stash the work, fix the urgent thing on its own branch, then pop it back
  • Commit the half-finished work so nothing is lost, then switch branches
  • Finish the current change first, since switching mid-change is not possible
  • Discard the current change and redo it after the urgent fix has been made

What did the whole day never use?

  • reset, rebase, --force, or history rewriting of any kind
  • Branches, since a single developer can work directly on main
  • The staging area, since git commit -a covers everything at once
  • Pull requests, since they are only needed on large teams with reviewers

You got correct