How do I save, collaborate and undo safely with Git?

Direct answer

Git records project changes in commits, while platforms such as GitHub provide hosting and collaboration. Saving a file is not committing it, and a local commit is not an upload. Three useful habits are changing one coherent thing, checking it, and inspecting differences before undoing anything. First establish whether work is committed, shared, or mixed with someone else’s uncommitted changes. Git documentation describes revert as adding a new commit that reverses an existing change; this differs from discarding working files or rewriting branch history.

When to use

• AI broke a feature and you want to restore working behavior.
• You work across computers, people, or agents.
• A push is rejected or a merge conflict appears.

Step by step

Identify the current repository state

Check the directory, branch, remote URL, and working-tree differences. Separate pre-existing user changes from this task. Before committing, inspect the file list for secrets, build output, temporary screenshots, and unrelated work. An ignore rule does not automatically untrack an already committed file.

Make one meaningful commit

Change and verify one explainable result, inspect each diff, and select the intended files. Describe the resulting behavior in the message. A real change might fix upload failures or add history; avoid mixing unfinished work into an unexplained “update.”

Understand remote changes before synchronizing

A commit creates local history; push transfers it to the remote. In collaboration, learn what others added and integrate according to project practice. Do not force-push after rejection without first checking whether the branch is behind, access is denied, or the remote is wrong.

Resolve conflicts by business intent

A conflict means edits overlap, not that either side can be chosen arbitrarily. Read both purposes, connected callers, and data structures, then form a result that meets current requirements. After removing markers, verify behavior; successful compilation does not prove another change was preserved.

Choose the undo scope and verify recovery

Preserve current work first and identify the file or commit to reverse. For a shared ordinary commit, consider revert; merge commits and later dependent changes require separate analysis. Reverting code does not restore a database or external-service state. A migration needs its own recovery plan.

Practice a small branch-to-merge flow

Git manages local versions, GitHub hosts repositories, clone creates a local copy, fork creates an independent platform repository, a branch isolates a line of work, and a PR requests review and merge. Start from a clean known baseline, change one piece of copy, inspect the diff, run relevant checks, then commit. If collaboration requires it, push the branch and inspect the PR’s base branch and complete diff. Review and merge through the project process. Commit, push, and production release are distinct; automatic deployment depends on branch configuration.

Preserve both intentions when resolving a conflict

Save current work, read both purposes, and determine whether the conflict concerns text or behavior. Edit the final content to preserve necessary intentions, remove markers, and test affected flows. Choosing “all mine” is not proof of resolution. Turn uncertain business choices into explicit questions while continuing unrelated work. Never use a force-push simply to remove a warning.

Worked example

Hypothetical exercise: undo copy without losing a fix

Imagine changing a title color, reviewing the diff, committing, pushing, and later deciding to undo that color. If an upload fix was added afterward, locate the color change instead of reverting the entire project to a point before the fix. A commit mixing color changes with many unrelated changes is harder to undo; this is why small, coherent commits help.

In another hypothetical case, one branch changes button wording while another fixes its disabled condition. The merge should keep both the wording and condition. Replacing the whole component with your version loses the fix. Verify that submission disables repeated clicks, not merely that conflict markers are gone.

Action checklist

• I know the current branch, remote, and uncommitted state.
• The commit contains only the agreed scope.
• Local history and remote synchronization are understood separately.
• Both affected behaviors were verified after conflict resolution.
• The undo scope is explicit and uncommitted user work and data are preserved.
• The branch, PR base, and both post-conflict behaviors have been checked.

Reusable templates

Analyze a safe undo before executing it

Working template
Undo [behavior or commit] while preserving [required work].
First inspect the branch, uncommitted changes, target commit, and later dependencies read-only. Do not automatically reset, delete files, or force-push.
Explain affected files and behavior, database or external-state effects, and the smallest recovery plan with verification. Execute only within current authorization after the scope is clear; preserve unrelated changes.

First Git collaboration exercise

Practice repository and baseline commit:
Current branch and uncommitted changes:
New branch: [for example practice/button-copy; follow project rules]
Only change in this exercise:
Diff and checks before committing:
Commit message: [reason and user-visible result]
Whether to push, and target remote/branch:
PR base / compare:
Conflict log: file | both intentions | merged behavior | verification
Merged commit and actual page:
Recovery: [a new reversing commit or another project-approved method]
Start with read-only observation using git status, git diff, and git log --oneline -5. Perform writes and pushes according to the repository process.

Pitfalls

• A force-push after a failed push can overwrite collaborators’ history. Diagnose first.
• Code hosting is not a database backup; user data is usually outside Git.
• Removing secrets from history is not sufficient incident handling. Revoke or rotate exposed credentials first.

Related guides

• How do I give AI enough evidence to diagnose a broken website?
• How do I deploy a local website, and why is a successful build not enough?
• Where should API keys and environment variables live, and what if one leaks?

Official references

• Git: git-revert — Explains reversing existing changes with a new commit, separately from discarding working-tree content. Recorded reference review date: 2026-10-18.

• GitHub: GitHub flow — Describes branches, commits, pull-request review, and merging. Recorded reference review date: 2026-10-18.