Make Changes Safely

Git records snapshots of a project's files and the relationship between those snapshots. A repository is the project history Git tracks. A commit is one named snapshot with an author, time, and explanation. GitHub can store a shared copy of that repository, but Git and GitHub are not the same thing.

A good commit contains one coherent change and explains why it exists. It gives you a point to review, share, compare, or restore. Saving a file records it on your computer; committing records a meaningful checkpoint in the project history; pushing sends commits to a shared repository.

A branch is a movable label pointing to a line of project history. It lets you develop a change without immediately moving the main line. When the change is reviewed and ready, it can be merged. Branches isolate history, but they normally share the same project folder.

A worktree gives another branch its own folder on disk. This is useful when two agents or two pieces of work need to run at the same time without rewriting the same files in one folder. The important rule is simple: know which folder, branch, and base commit each worker owns before it starts editing.

More branches do not automatically create safety. Safety comes from clear ownership, small scope, current base history, reviewable diffs, and an intentional merge.

A diff shows what changed between two versions: added lines, removed lines, and modified files. It is the primary surface for reviewing an agent's work. Start with the list of changed files, then inspect configuration, data models, permissions, external actions, and deleted behavior before cosmetic details.

Ask the agent to explain surprising changes, but verify the explanation against the diff. Generated summaries can omit accidental edits. If the diff is too large to understand, the change is too large to accept as one unit.

A test is a repeatable check of expected behavior. A unit test checks a small piece of logic. An integration test checks components working together. An end-to-end test follows a user path through the running system. A manual check is still useful, but it is harder to repeat consistently.

Tests reduce uncertainty; they do not prove the absence of every problem. Match each test to a risk. A formatting function needs deterministic examples. A database workflow needs integration coverage. A checkout or approval flow needs a complete user-path test. A visual page needs inspection at realistic screen sizes.

Development is where you make and debug changes. A preview or staging environment lets people inspect a candidate version away from production. Production is the environment real users depend on. Each can have different data, secrets, domains, permissions, and infrastructure.

Deployment is the controlled act of placing a specific version into an environment. A successful build says the code could be packaged. A successful deploy says a platform accepted a version. A live verification says the intended behavior is actually visible in that environment. Keep those claims separate.

Rollback means returning to a previously known version or reversing a change. Code rollback may be simple; data rollback can be much harder because users may have created new records after deployment. Plan the recovery path before a consequential release.

Before approving an agent-made change, know the last good version, the signals that indicate failure, the person authorized to reverse it, and whether any data transformation is backward compatible. Reversibility is a design property, not an emergency command you improvise later.