What a Writer Notices When Learning Git

Németh Mária — Sun, 25 Oct 2026 10:08:33 +0000

I'm a writer who's learning to code, and Git was the first tool that really slowed me down. Commands like rebase and detached HEAD sounded alarming. Then something clicked: a lot of Git maps onto habits writers already have. Here are the comparisons that helped me, plus a few commands I now use every day.

Commits are like saved drafts with a note attached

Writers keep versions: "draft 2", "draft 2 – shorter intro", "final_FINAL". Git does the same thing, minus the messy file names. Each commit is a snapshot, and the message explains what changed.

The habit that helps most is making commits small and focused, the same way an editor prefers one clear change per round of edits.

Commit messages are tiny pieces of writing

A good commit message works like a good headline: short, specific and active.

Fix broken link in installation guide

The old link pointed to a page that was removed.
Updated it to the current setup docs.

Some conventions I picked up:

Keep the first line short, around 50 characters.
Use the imperative: "Add", "Fix", "Remove", not "Added" or "Fixing".
Leave a blank line, then explain why if it isn't obvious.

"Update stuff" tells your future self nothing. "Fix typo in README title" tells them everything.

Branches are like trying a different version of a chapter

When you want to rewrite a section without losing the original, you make a copy and experiment. A branch does exactly that:

git switch -c new-intro   # start a new branch and move to it
# ...edit files...
git add .
git commit -m "Rewrite introduction for beginners"
git switch main           # go back to the original

If the experiment works, you merge it. If it doesn't, the original never changed.

`git diff` is track changes

If you've ever reviewed tracked changes in a document, git diff is the same idea: removed lines in one colour, added lines in another. Running git diff before every commit has become my version of proofreading. It's where stray debug lines and half-finished sentences get caught.

Commands I actually use most

As a beginner, I found the full list of Git commands overwhelming. These cover most of my day:

git status shows what changed and what's staged
git diff shows exactly what changed
git add <file> stages a change
git commit -m "message" saves a snapshot
git log --oneline gives a short history
git switch <branch> moves between versions

Still learning

Merge conflicts still make me nervous, and I've only just started reading about rebase. But thinking of Git as version control for writing, which is what it is, made it feel much less foreign.

If you came to coding from a non-technical background, which comparison made Git click for you?

Writing a README People Actually Read: Notes From a Writer Learning to Code

Németh Mária — Thu, 22 Oct 2026 10:10:20 +0000

I'm learning to code. Along the way I've noticed something: the part of a project I understand fastest is usually the README. When a README is unclear, I often give up before I ever open the code.

Writing is the part I'm comfortable with, so here are the habits I keep coming back to when I read (and try to write) READMEs.

Start with one sentence that says what it is

The first line should answer "what is this, and who is it for?" Most visitors decide within seconds whether to keep reading. A sentence like "A command-line tool that renames photos by the date they were taken" does more work than three paragraphs of background.

Show it working before you explain it

People want to see the result first. A short example near the top beats a long feature list:

## Quick start

    npm install my-renamer-tool
    my-renamer-tool ./holiday-pics

Before: IMG_4021.jpg
After:  2026-08-14_10-32-05.jpg

Once readers can see what happens, the details that follow make sense.

Write install steps as if the reader knows nothing

It's easy to skip steps that feel obvious to you. When I follow installation guides as a beginner, the missing piece is almost always something the author did without thinking: a required version, an environment variable, a folder you must be in. Numbered steps, one action each, are hard to get wrong.

Use headings as a map

Many readers scan instead of reading top to bottom. A predictable set of headings helps them jump to what they need:

What it is
Quick start
Installation
Usage
Configuration
Contributing
License

Not every project needs all of them, but sticking to familiar names means people don't have to guess.

Cut the words that don't help

Editing habits carry over well from ordinary writing:

Replace "In order to" with "To".
Delete "simply" and "just". If the step were simple, the reader wouldn't be in the docs.
Keep paragraphs short. Three or four lines is plenty on a screen.

Keep it true

A README that describes last year's version is worse than a short one. If a command changes, the README should change in the same commit. That's a coding habit I'm still building, but it's the one that seems to matter most.

What I'm still figuring out

I haven't settled how much detail belongs in the README and how much should move to separate docs. My current rule of thumb: the README gets someone from "what is this?" to "it works on my machine". Anything beyond that gets its own page.

If you have a README you think does this really well, I'd love to see it in the comments. Good examples are the best way I've found to learn.

DEV Community: Németh Mária