Git-friendly habits for beginners

An AI coding agent can change a lot of code in minutes, so a few simple git habits decide whether that speed helps your team or hurts it. Git is the tool that records every change to a codebase, so you can review it or undo it later.

Say you asked Codex to fix a null check in a checkout helper before lunch. The patch looked fine in the chat summary, so you saved it straight to the shared main branch with the message “fix stuff,” pushed it, and left. An hour later a teammate’s pull request (a proposed change waiting for review) no longer merges cleanly. Soon someone asks why a test file disappeared, and by mid-afternoon you are searching for how to undo a git push without breaking everything. The model did not ruin your day. The missing git habits did.

This post closes the ChatGPT Codex / coding tutorial. The earlier posts covered opening Codex and a first project, exploring a codebase safely, the skills, tasks, and scheduled help the product offers, and a review loop where green checkmarks are not a ship button. Here we make the team layer boring on purpose. That means one branch per task, small commits, clear messages, pull request review, never rewriting shared history blindly, and a few undo basics you can use without drama. Codex is done when you can change code, review it, and reverse course without rewriting history like a thriller plot. Next on the ChatGPT track is the Custom GPTs tutorial.

Git hosting sites and Codex screens change often, but the habits below last. Re-check your team’s branch protection rules and OpenAI’s current Codex docs the week you write team policy.

Why git habits matter more with Codex

Without an agent, a messy git day often means a few files and a confused afternoon. With Codex (or any coding agent), a single session can touch many files, rewrite tests until they pass, and reformat unrelated folders. That leaves you with a diff (the list of exact line changes) that looks successful in chat and reckless in review. Speed multiplies both good and bad process.

Git is not a status symbol. It is a time machine and a team agreement, and each part has a job. A branch keeps risky work away from everyone else’s code, and a commit is a restore point you can return to. The commit message is the story other humans (and future you) read under pressure, and a pull request forces a second look. A force-push rewrites shared history, so treating it casually is how trust evaporates.

The earlier post on review already said to read the diff, run tests, check for secrets, check scope, and let a human make the commit. This post is the packaging around that loop, so your good review does not land as a pile of anonymous noise on main.

The five-habit loop

Memorize this sequence the way you memorize “look both ways” before crossing a street. It is the whole post in one strip.

Habit 1: branch per task

Start every Codex job that will edit shared code on a named branch. The reason is not ceremony. Isolation is cheap and recovery is expensive.

Name the work before you open the agent

Pick a branch name that matches the ticket or the one-sentence goal, like these:

git switch -c fix/checkout-null-guard
git switch -c feat/export-csv-button
git switch -c chore/bump-lint-config

If your hosting site already created a branch from the issue, use that one instead of inventing a second name for the same work.

One goal per branch

Codex loves to helpfully “also clean up” nearby files. Your rule for each branch is one main idea. If the agent starts a second idea, such as renaming a module while fixing a null check, stop, restore the extras or move them to a new branch, and keep the pull request reviewable. Working across several files is fine, but working on several missions at once is never free.

Never use main as a scratchpad

main (or master, or your release branch) is for integrated, reviewable work. Agent experiments, half-finished prompts, and “let me try something wild” belong on throwaway or feature branches. If your team has branch protection, which blocks direct changes to protected branches, good. If not, behave as if it exists, because your future self is also a teammate.

Habit 2: small commits

Agents can generate a large patch in one sitting. That does not mean you must store it as one opaque blob, because small commits are both restore points and teaching tools for reviewers.

What “small” means in practice

Small does not mean one character. It means one coherent step that a human can describe out loud. For a typical Codex session that might look like this:

• Commit A: failing test that captures the bug.
• Commit B: production fix.
• Commit C: docs or comment only if truly needed.

For a feature it might look like this instead:

• Commit A: a change to the types or interface.
• Commit B: implementation.
• Commit C: tests.

If the agent dumped everything at once, you can still stage in slices before you commit. Use git add -p (patch mode, which lets you pick pieces of a change) or stage specific files. You are allowed to reorganize the story even when the model produced a single wave of edits.

What not to mix

If Codex reformatted half the tree while fixing a bug, restore the unrelated formatting, open a separate cleanup pull request later, or reject the run and ask again with a tighter scope. Telling the agent what not to touch is a git habit, not only a chat habit.

Habit 3: descriptive commit messages

A good message answers two questions in plain language: what changed and why it matters. It is not a diary of your prompt history, and reviewers should not need the chat transcript to understand the commit.

A simple shape that works

Short summary in imperative mood (about 50 chars)

Optional body: why this change exists, what you verified,
and anything a reviewer should not miss.

Refs: TICKET-123

These examples pass the standup test, meaning you could say them out loud to your team without cringing:

fix null guard on checkout when cart is empty

Empty carts hit getItems() without a list. Guard returns early
and adds a unit test for the empty path. Manual check: empty cart
page no longer 500s.

Refs: SHOP-441

Add CSV export for weekly sales report

Exports the same columns as the on-screen table. Uses streaming
writer for large ranges. Verified on sample of 5k rows.

Refs: ANALYTICS-88

Messages that fail the standup test

• fix, updates, misc, wip, asdf
• codex did this, which is true but not helpful.
• A full paste of the prompt chain.
• Jokes that hide a production risk.

If Codex drafts a commit message for you, treat it as a first draft and rewrite anything you could not defend. The rule from the review post still stands, which is that a human owns the commit button and the story attached to it.

Habit 4: pull request and real review

A pull request (PR) is a forced pause. It turns “I think this is fine” into something others can review, with a title, a description, a file list, test results from continuous integration (CI, the automatic checks that run on every change), and comments. Even if you are a solo developer, a PR gives you those automatic checks, a second look tomorrow morning, and a paper trail when something breaks.

What belongs in a Codex-assisted PR description

## Summary
- Ticket / goal:
- One sentence: what this PR is supposed to do

## Agent assist
- [ ] Codex (or other agent) used
- Scope I asked for:
- Extra files the agent touched (and what I did):

## Verification
- [ ] I read the full diff (not only the chat summary)
- [ ] Tests / commands run:
- [ ] No secrets or customer PII in the patch
- [ ] Scope matches the ticket

## Risk
- What could break:
- Rollback: revert this PR / feature flag / follow-up

You do not need a novel, only honesty. A line like “Codex also rewrote the logging module, and I restored it” is exactly what a reviewer wants to read. A comment like “Looks good to me, AI wrote it” is not a review.

Review checklist for an agent-assisted pull request

• Diff: open the full file list; watch for unrelated paths and deleted tests.
• Tests: the automatic checks pass on this branch, and you run the risky path locally if those checks are thin.
• Secrets: no keys, tokens, .env bodies, customer dumps.
• Scope: matches the ticket; no surprise architecture rewrite.
• Human commit and merge: a person who understands the change presses the button.

If your team requires status checks on protected branches, treat a failing check as a stop sign, not a suggestion. Merging a red result just to unblock someone is how bugs from an agent turn into outages in production.

Habit 5: never force-push blind

Force-push rewrites history on the remote. Sometimes that is correct on a private feature branch that only you use. Often it is a landmine, because someone else may have already pulled the old version, the automatic checks may be mid-run on old commits (each identified by a code called a SHA), or you may be cleaning up after Codex without fully understanding what you are erasing.

Default rules that keep teams sane

• Never force-push main, release branches, or any shared long-lived branch.
• Prefer new commits (including reverts) over rewriting published history.
• On a personal feature branch: force-with-lease is safer than a plain force if you must rewrite, because it fails when the remote copy has changed in ways you have not seen. Even then, you should know who else uses that branch.
• If Codex or a tutorial suggests force-push as the first fix, pause and ask whether a reverse commit or a new PR would leave a clearer record.

Branch protection on GitHub, GitLab, and similar hosts can block force-pushes to protected branches. Turn that on, because a product setting beats a sticky note that says “please don’t.”

When people reach for force-push (and better options)

Force-push is a sharp tool, and sharp tools belong in trained hands with a reason. They should not be a reflex that says Codex made a mess, so erase the evidence.

Undo basics (without rewriting the universe)

You will need undo, and agents make that more common, not less. Learn a small kit of commands, and practice on a throwaway repository once so panic is not your first teacher.

See what is going on

git status
git diff
git diff --stat
git log --oneline -n 10

If you cannot explain the output of those four commands, do not run destructive history commands yet. The warning signs from the review post pair well here, which are unrelated files, deleted tests, secrets, huge rewrites, and suggestions to force-push.

Unstage or discard local work

# Unstage a path (keep file contents)
git restore --staged path/to/file

# Discard uncommitted changes in a path (destructive to working tree)
git restore path/to/file

# Discard everything uncommitted (nuclear; be sure)
git restore .
git clean -fd   # removes untracked files; double-check first

When Codex only spoiled two files, restore those two paths instead of reaching for the nuclear options.

Undo a commit that never left your machine

# Keep changes staged, remove last commit
git reset --soft HEAD~1

# Keep changes unstaged, remove last commit
git reset HEAD~1

# Throw away last commit and its changes (only if you are sure)
git reset --hard HEAD~1

The --hard option deletes work, while the soft and default options keep your edits so you can recommit cleanly. When in doubt, try soft first.

Undo something already pushed (shared branch)

Prefer a reverse commit, which future readers of the history can see:

git revert HEAD
# or revert a specific SHA
git revert abc1234
git push

A revert adds to the history, which is a feature on shared branches. Force-pushing to pretend the bad commit never existed is how teammates’ copies drift apart and incident notes get fuzzy.

“I committed a secret”

Order of operations: replace the credential first, whether it is an API key, a password, or a token. Assume anything pushed is compromised. Then remove the secret from the code going forward, and follow your organization’s process for history cleanup if it requires one. Do not treat rewriting git as the main fix while the old key still works out in the world.

A Codex session that ends clean

Here are the five habits combined into one routine you can start on Monday.

1. Name the goal in one sentence, because if you cannot, you are not ready for edits across many files.
2. Branch from an up-to-date default branch: git switch main && git pull && git switch -c …
3. Set limits in the prompt: what to touch, what not to touch, and how to run tests.
4. Let Codex edit on that branch only, with no silent side trips into deploy scripts.
5. Review with the loop from the earlier review post: diff, tests, secrets, and scope.
6. Commit in slices with messages you can defend, and stage each piece on purpose.
7. Push the feature branch and open a PR, filling in the agent-assist section honestly.
8. Merge only when the review and the automatic checks agree. You or a teammate own the button.
9. If something goes wrong, restore paths, soft-reset local commits, or revert on shared history, and do not force-push blind.

That is the whole series packaged as muscle memory. Explore safely, add complexity on purpose, review hard, and package the work with git habits that other humans can live with.

Worked mini-example: one bug, one branch, two commits

Imagine a tiny Python helper that should return zero items for an empty cart but currently throws. You branch first and then open Codex.

git switch -c fix/empty-cart-count
# Prompt (sketch): “Add a failing test for empty cart item count,
# then fix cart.py only. Do not reformat other packages. Show the diff.”

After review, you stage and commit in two steps:

git add tests/test_cart.py
git commit -m "$(cat <<'EOF'
Add failing test for empty cart item count

Empty carts should report zero items. Captures the current throw
so the fix is locked in.

Refs: SHOP-441
EOF
)"

git add src/cart.py
git commit -m "$(cat <<'EOF'
Return zero items when cart list is missing

Guard get_item_count before iterating. Keeps existing behavior for
non-empty carts. Tests green locally.

Refs: SHOP-441
EOF
)"

git push -u origin fix/empty-cart-count
# open PR, paste verification notes, wait for CI

Notice what you did not do. You did not commit on main, save one vague “fix cart” blob, force-push after rewriting, or merge before reading the diff. The agent wrote the code, and you wrote a history that a teammate can trust.

Common mistakes

• Committing on main because “it was a one-liner.” Even one-line changes can break a build.
• Trusting the chat summary instead of git diff. Summaries skip files and soften the risk.
• One mega-commit for a whole agent afternoon. You cannot restore a state from the middle of the work.
• Letting Codex delete flaky tests to get green. That is hiding a fire under a coat of paint.
• Force-pushing after a shared PR already has review comments. Comments point at old versions of the code, and people get lost.
• Putting secrets in the repo “just for local Codex.” Local secrets still leak when you push the wrong path.
• Skipping PR description honesty about agent use. Reviewers need to know where the real risk is.
• Using Work for code or Codex for press releases. Each is the wrong tool, and a mistake in the wrong tool can spread far (see the Work series).
• Learning force-push before learning restore. Learn to reverse and recover first, and force-push much later.

Practice this week

1. Clone or open a throwaway repo, and create practice/agent-git-habits.
2. Make a deliberate mess: edit three files, stage two, commit one bad message on purpose.
3. Practice git restore --staged, git restore on a path, and git reset --soft HEAD~1.
4. Run a tiny Codex (or manual) fix on a new branch with a clear message and open a draft PR.
5. Write a five-line PR description using the agent-assist template above.
6. Optional: on that solo branch only, try an interactive rebase or soft reset, then push with a normal (non-force) update if you rewrote nothing published. If you do not fully understand the command, skip force entirely.
7. Note one personal rule you will keep: for example “no commits on main” or “always git diff --stat before commit.”.

What this Codex series covered

ChatGPT Codex / coding tutorial was the deep coding-agent track for people who will touch a real project with ChatGPT’s coding tool:

If you keep one idea from the whole series, keep this one. Codex is a strong pair-programmer with tools, not an unsupervised release engineer. Explore before you edit, add complexity on purpose, and review diffs like a skeptic. Then package the work so that git history and your teammates can survive your speed.

Where this sits on the ChatGPT path

Orientation and earlier tracks still matter when you are choosing which product fits a job:

• Learn ChatGPT from scratch for foundations, privacy, and everyday judgment.
• ChatGPT product map for Chat vs Work vs Codex vs other flavors.
• ChatGPT everyday tutorial for human-led Chat skills.
• ChatGPT Work tutorial for multi-step office deliverables with approvals.
• ChatGPT Codex / coding tutorial (this series, complete).

What comes next in the ChatGPT track

This closes the ChatGPT Codex / coding tutorial. The next deep track on the plan is the Custom GPTs tutorial. It covers building a simple GPT for a repeating task, writing its instructions, adding knowledge files and light actions, sharing it with a team without chaos, and knowing when a Custom GPT is the wrong solution.

Custom GPTs are not “Codex but friendlier.” They are packaged recipes for chat-shaped work: a stable instruction set, optional files, optional actions, shared with a group. You bring the same judgment you practiced here (scope, secrets, verification), applied to prompts and knowledge instead of pull requests. Do not paste production credentials into a GPT’s knowledge files just because the builder makes it easy. Do bring along the habit of writing down what the thing is for and what it must never do.

If your day job is still pure software on a repo, stay on the Codex habits in this post and keep shipping through PRs. If your day job is writing the same analysis brief twelve times a month, Custom GPTs are the next lesson. Picking the right tool for the job is the point of the whole ChatGPT track on this site.

Quick recap

• Branch per task; keep main clean.
• Prefer small commits you can restore and explain.
• Write messages that pass the standup test.
• Open a PR, review the real diff, and keep the automatic checks honest.
• Never force-push blind on shared history, and prefer a revert on shared copies.
• Learn the undo kit: status, diff, restore, soft reset, and revert.
• The series is done, moving from opening Codex to exploring, adding features, reviewing, and finally git habits.
• Next up is the Custom GPTs tutorial, which covers packaged chat recipes rather than coding agents.

Sources

Research and further reading used for this article:

• Git: Official documentation (core commands, reset/restore/revert concepts)
• Git: git-reset (soft, mixed, hard semantics)
• Git: git-restore (unstaging and discarding working tree changes)
• Git: git-revert (undo on shared history without rewriting)
• Git: git-push (including force and force-with-lease notes in official docs)
• GitHub Docs: Collaborating with pull requests (PR workflow and review culture)
• GitHub Docs: About protected branches (blocking force-push and requiring reviews)
• GitHub Docs: Removing sensitive data from a repository (secrets in git; rotate first mindset)
• OpenAI Help: ChatGPT Work and Codex (Chat vs Work vs Codex product split)
• OpenAI: Introducing Codex (product context for the coding agent surface; verify current product pages as names move)
• Analytics Made Simple: ChatGPT Codex / coding tutorial (this series)
• Analytics Made Simple: ChatGPT Work tutorial (approvals and non-code agent work)
• Analytics Made Simple: Learn (related paths on this site)

Merch on Etsy

Open store →

Standard Deviation T-Shirt View on Etsy → Naive Bayes Coffee Mug View on Etsy → Git Version Control Shirt View on Etsy → Apache Iceberg T-Shirt View on Etsy →