Version control records changes so you can inspect history, compare revisions and recover earlier work. It helps collaboration, but it does not automatically keep every checkout synchronized or preserve files you never recorded.
Inspect history before changing it
In a practice Git repository:
git status
git diff
git log --oneline -5
Status shows the working tree’s relationship to the current commit. Diff shows changes, and log lists recorded commits. These commands inspect; they do not publish your work.
A commit is local
Staging selects what goes into the next commit. Committing records it locally. Pushing shares commits with a remote; fetching obtains remote history, and integrating that history changes your local branch. Those are distinct steps.
A branch is a pointer to a line of commits, not a duplicate directory. See feature branches for working-tree implications. Avoid destructive reset commands as a casual way to “sync” a project with unrelated changes.
Distributed does not mean always complete
Git is distributed: local repositories can hold history and make commits without contacting a central server. Shallow or partial clones may contain less than the entire history. Mercurial is also distributed; the previous version of this article incorrectly called it centralized.
Do not commit credentials or private data. Ignoring a file does not remove it from history if it was already committed. Keep remote sharing and release policies explicit so a recorded change is not mistaken for a deployed one.
Sources
Reference 1 Reference 2 provide the technical details and current compatibility information.