A day in the life

Why this matters

You now know every command and every page. This lesson puts them in order, once, as a day actually goes. If you follow it for your first few changes, the sequence becomes automatic and you stop thinking about Git at all, which is the goal.

The whole day

Morning

1. Pick up the issue

Assign it to yourself, so nobody duplicates the work, and read it twice. If anything is ambiguous, ask in the issue rather than in chat: the answer then lives where the next person will look (lesson 13.9).

2. Start from current main

$ git switch main
$ git pull

Branching from a stale main is the most common cause of conflicts later (lesson 11.6).

3. Make the branch

$ git switch -c docs/12-windows-install-steps

The issue number in the name is what links the branch, the commits and the merge request together (lesson 6.2). Many teams start the branch from the issue page instead, which names it for you.

4. Do the work

One thing at a time. If you notice something else that needs fixing, write it down as a new issue rather than adding it here: a merge request about two things takes twice as long to review and is twice as likely to be sent back.

Midday

5. Check it yourself

Read .gitlab-ci.yml or .github/workflows/*.yml and run what the pipeline runs:

$ npx --yes markdownlint-cli "**/*.md" --ignore node_modules
$ python3 -m unittest discover -s tests -v

Ten seconds here saves a ten-minute round trip later (lesson 9.10).

6. Commit

$ git status
$ git add docs/getting-started.md
$ git diff --staged
$ git commit -m "docs: add Windows steps to installation guide (#12)"

git diff --staged before every commit is the habit that catches the debugging line you left in.

7. Push

$ git push -u origin docs/12-windows-install-steps

The output contains the link to open the merge request, which saves finding it in the interface.

8. Open it as a draft

Title, then a description with what, why, how to check and Closes #12. Add reviewers. Mark it a draft while you are still working (lesson 9.7).

Opening early is deliberate: the pipeline starts running, and a colleague can say "that is the wrong file" before you have spent the afternoon on it.

Afternoon

9. The pipeline and the review

The pipeline runs on every push. If it is red, open the failing job, read upwards from the end of the log, and fix what it names.

Review comments arrive as threads. Answer every one, even with "done" or "kept as is, because…" (lesson 9.8).

10. Push fixes

$ git add docs/getting-started.md
$ git commit -m "docs: address review comments on the Windows steps"
$ git push

New commits, not amends: the reviewer needs to see what changed since they looked. The squash on merge tidies it up.

Then Mark as ready, and re-request review.

11. Approve and merge

When the pipeline is green and the approvals are in, merge with the option your team uses, ticking Delete source branch (lesson 13.4). The issue closes itself, because the description said Closes #12.

12. Clean up

$ git switch main
$ git pull
$ git fetch --prune
$ git branch -d docs/12-windows-install-steps

Thirty seconds, and it keeps your branch list meaningful. Then pick up the next issue.

The same day on GitHub

Identical, with four words changed:

The commands do not change at all (terminology map).

What the day is actually made of

Of the twelve steps, two are your work: step 4 and step 10. The other ten are the same every time, which is exactly why they are worth turning into a routine rather than a decision. Experienced people do not think faster about steps 2, 3, 7 and 12; they do not think about them at all.

How to do it

$ git switch main && git pull
$ git switch -c docs/12-windows-install-steps
$ git status && git add <file> && git diff --staged
$ git commit -m "docs: … (#12)"
$ git push -u origin HEAD
$ git commit -am "docs: address review comments" && git push
$ git switch main && git pull && git fetch --prune
$ git branch -d docs/12-windows-install-steps

Common mistakes

• Branching from a stale main, which produces avoidable conflicts.
• Committing to main by habit (lesson 12.7).
• Two unrelated changes in one merge request.
• Waiting until the work is perfect to open the merge request. Open a draft early.
• Not running the pipeline's own commands locally.
• Leaving the branch behind after merging, so everyone's branch list grows.