1. Understand What Git Tracks
Git is a version control system: it records changes to a project so you can compare versions, develop ideas separately, and recover earlier work. It runs locally and does not require a hosting service. Platforms such as GitHub can host remote repositories for collaboration, but Git and GitHub are not the same thing.
Three areas explain most everyday commands. Your working tree contains the files you edit. The staging area holds the changes selected for your next commit. The repository stores committed snapshots and their history. Saving a file changes your working tree; it does not automatically stage or commit anything.
To start tracking an existing project, open a terminal in its folder and run git init -b main. This creates a repository with main as the initial branch name. Run git status to see what Git currently knows about your files. Make this command a habit before and after important operations.
2. Create Small, Meaningful Commits
A commit records the staged state of your project, together with information such as an author and message. Before your first commit, configure your identity with git config --global user.name "Your Name" and git config --global user.email "you@example.com", replacing the placeholders. These values become commit metadata; they are not login credentials.
Suppose you edited README.md. Run git diff to inspect unstaged changes to tracked files, then git add README.md to stage that file. Run git diff --staged to review exactly what the commit will contain. Finally, run git commit -m "Clarify project setup instructions". If you edit the file again after staging, those additional edits remain unstaged until you add them.
Aim for one coherent change per commit. Smaller commits are easier to review and undo than a mixture of unrelated fixes. Although git add . is convenient, it can stage unintended files. Check git status and maintain a .gitignore file for generated output, local settings, and secrets. Ignore rules do not stop Git from tracking files already committed.
3. Use Branches to Separate Work
A branch is a movable reference to a commit, not a separate copy of the entire project. Branches let you work on an improvement without immediately changing your main development line. From a clean working tree on main, run git switch -c improve-navigation to create a branch and switch to it.
Edit files, stage changes, and commit as usual. Those new commits advance improve-navigation while main remains where it was. Run git branch to list local branches and git log --oneline --graph --all to inspect their history.
Before switching branches, check git status. Uncommitted changes may follow you to another branch, or Git may refuse the switch if it would overwrite them. Commit coherent work first. For a temporary interruption, git stash push -u can set aside tracked changes and untracked files, but not ignored files. Later, git stash apply restores the latest stash while keeping its saved entry.
4. Merge Changes and Resolve Conflicts
To bring your completed work into main, first ensure the working tree is clean. Run git switch main, then git merge improve-navigation. Depending on the history, Git may move main forward directly, called a fast-forward, or create a merge commit that connects the two lines of development.
A conflict occurs when Git cannot combine changes automatically. Run git status to identify affected files. For a typical text conflict, open the file and find the sections separated by conflict markers. Edit the result to contain the intended content and remove the markers. Do not automatically choose one side without understanding what both changes accomplish.
Stage each resolved file with git add, then run git commit to complete the merge. Review and test the result: a merge without conflicts can still introduce incorrect behavior. If you need to abandon an unresolved merge, git merge --abort attempts to restore the pre-merge state. Starting with a clean working tree makes that recovery more reliable.
5. Recover Without Losing More Work
First identify whether the mistake is unstaged, staged, or committed. To unstage README.md while keeping its edits, run git restore --staged README.md. To discard unstaged edits, git restore README.md replaces the working-tree file with its staged version. That second command can destroy uncommitted work, so inspect the changes and copy anything valuable before using it.
To correct the latest commit message, use git commit --amend -m "Better message". Amend also includes any currently staged changes and replaces the previous commit. Use it for unpublished work; changing shared history can disrupt collaborators.
For an ordinary commit already shared with others, git revert COMMIT_ID creates a new commit that reverses its changes rather than erasing history. Replace COMMIT_ID with the identifier shown by git log. If a commit seems lost after moving a branch, git reflog may reveal it. Run git branch recovered-work COMMIT_ID to preserve an available commit. Reflog is local, temporary history—not a backup or a way to recover never-committed edits.
6. Build a Repeatable Daily Routine
Use a simple cycle: check status, choose a branch, edit, review differences, stage intentionally, and commit. Before merging, review the history and run the project's checks. Local commits are not uploaded automatically; publishing requires a configured remote and a push. Keep appropriate backups too. Git becomes easier when each command has a clear purpose and each change stays small enough to understand.
