The daily routine

Why this matters

Most Git trouble is not caused by hard problems; it is caused by skipped small steps: a day of work that was never pushed, a pull that was never done, a commit made without looking. A routine makes the steps automatic. This one takes about five minutes a day and prevents nearly everything Section 12 exists to repair.

Morning: start from the truth

1. Open the project and look: git status. Which branch, is the tree clean, is there a stash from yesterday?
2. Sync: git switch main and git pull. Now your main is what the team's main is.
3. Branch for today's work (Section 6): git switch -c docs/34-release-notes, or switch to the branch you were on and update it from main.

Why: a branch created from a stale main produces conflicts later; a forgotten stash or an unexpected dirty tree is best discovered at 9:00, not at 17:55.

During the day: small loops

1. Edit one thing.
2. Look: git status, git diff.
3. Stage what belongs together: git add <files>; git diff --staged for anything non-trivial.
4. Commit with a message that names the change and the issue.
5. Push when a piece is done, before lunch, before a meeting, before leaving your desk for long.

A rhythm to aim for: a commit every time something is finished enough to describe in one sentence, typically every 20–60 minutes; a push every hour or two. Commits are free and local; pushes are backups and visibility.

Before you push

Ten seconds:

• git log --oneline origin/main..HEAD (or git log --oneline -5): are these the commits you meant?
• git status: nothing important left uncommitted?
• If the branch is shared or you have been away for a while: git pull first, then push.

End of the day

1. Commit or stash whatever is half done (a wip: commit on your own branch is fine; you can squash it later).
2. Push your branch. A laptop can die overnight; the server does not.
3. Update the issue or the merge request with a line about where you are, if anyone is waiting.

Why: pushed commits are the only work that survives a broken laptop or a sick day when a colleague has to take over.

When you are in a hurry

Never skip: the git status before git add, and the push at the end of the day. Everything else can compress: git commit -am for a one-file change you have looked at, git pull without a fetch first when you know nobody else touched the branch.

Common mistakes

• Working on main because "it's a small change". Branch anyway; it is one command.
• Pulling only when pushing fails. By then the merge is bigger than it needed to be.
• Giant commits at the end of the day. Reviewers hate them and reverts cannot split them. Commit as you go.
• Leaving a stash unnamed overnight. Tomorrow's you will not remember.

Try it yourself

Goal: run the full routine once on the playground.

1. Morning: git status, git switch main, git pull (if you have a remote), git switch -c docs/routine-practice.
2. During the day: make two small commits in two loops (status → diff → add → commit).
3. Before push: git log --oneline -3.
4. End of day: push the branch if you have a remote (git push -u origin docs/routine-practice); otherwise note that you would.

Expected result: two commits on a fresh branch, visible in the log; a pushed branch if a remote exists.

Show solution

The point is the order, not the commands: look, sync, branch, small loops, look before pushing, push at the end. Switch back with git switch main when done; the practice branch can stay or be deleted with git branch -d docs/routine-practice after merging or -D to discard it.

Check yourself

1. Which step should you never skip, even when in a hurry?

git diff --staged before every commit Naming stashes git status before git add, and a push at the end of the day

2. Why pull main first thing in the morning?

So that today's branch starts from the team's current version and avoids conflicts later Because the pipeline requires it To trigger a backup

Check answers