Git from Local Changes to Reviewed Collaboration
Git records snapshots of a project and connects them into a history.
- Author
- absequ
- Published
- Updated
- Category
- Version control
- git
- version control
- practical guide
Git records snapshots of a project and connects them into a history. A remote hosting service can share that history, but a local repository already supports commits, branches and comparisons. Learning the distinction between working files, the staging area, local commits and remote branches makes everyday collaboration safer and easier to explain.
On this page
The mental model
The working tree contains editable files. The index, often called the staging area, describes the snapshot intended for the next commit. A commit records that snapshot with metadata and parent relationships. Saving a file does not stage it, and staging a file does not publish it to a remote.
A branch is a movable reference to a commit, not a separate permanent copy of every file. Creating a branch provides a place for subsequent commits to advance. Remote-tracking references describe the remote state known from a fetch; they are not proof that the server has remained unchanged since then.
A practical workflow
Begin each task by checking the branch and working-tree status. Inspect changes before staging, and stage explicit paths when other work is pending. Review the staged diff separately because the working-tree diff does not include everything already staged, and untracked files are not included in an ordinary diff.
Make commits that explain one coherent change and can be reviewed or rolled back independently. Before pushing, confirm the destination, upstream and unpublished commits. A normal push should be preferred; a force push rewrites a shared reference and needs an explicit team policy and authorization.
Worked example
git status --short --branch
git switch -c docs/example-change
# Edit only the intended files, then inspect them.
git diff -- README.md
git add -- README.md
git diff --cached --check
git diff --cached --stat
git diff --cached -- README.md
# Commit only after review; this example does not push or change a remote.The staged view is the important review boundary for the next commit. If a file contains two unrelated changes, selective staging can separate them without discarding either. Verify the resulting index content rather than assuming the whole file belongs to the same task.
For collaboration, fetch and inspect incoming history before deciding how to integrate it. Resolve a conflict by understanding the intended final behavior, not simply selecting one side's text. Re-run relevant tests after resolution and review the complete result, since a syntactically resolved conflict can still introduce a functional defect.
Failure modes and security
Do not commit credentials or private keys. Removing a secret from the latest file does not revoke it or erase earlier commits. Credential containment and any history rewriting need a deliberate plan; rewriting history can affect other collaborators and automation.
Destructive commands, unreviewed resets and broad staging can discard work or include unrelated files. Avoid copying recovery commands from a tutorial without checking the current repository state. A clean working tree means local files match the index and commit, not that the application is correct or synchronized with every remote.
Practice and verification
Create a disposable local repository and make two changes in one file. Stage only one, inspect both staged and unstaged diffs, and explain what the next commit will contain. Then create a second branch with a conflicting edit and resolve the conflict deliberately. Use synthetic text and no credentials. Finish by drawing the difference between local HEAD, its parent and the last fetched remote-tracking reference.
References
Git tutorial — Git
Git status — Git
Git diff — Git