Git basics: repositories, staging and commits

Why version control?

Without version control, teams email zip files or keep folders called final, final2 and final-really. Nobody knows which copy is current, and an old version is lost the moment someone saves over it. A version control system records every change to a set of files, with the author, the time and a message saying why. You can compare any two versions, find which change broke something, and undo it.

Git is the version control system almost every team uses today. It is distributed: every developer has a full copy of the whole history on their own laptop, not just the latest files. You can commit, view history and create branches with no network at all. A shared server such as GitHub, GitLab or Bitbucket is simply one more copy that everyone agrees to sync with.

The three areas

The staging area is what makes Git different from a simple backup. If you changed three files but only two belong to the bug fix, you stage those two and commit them with a clear message. The third change waits for its own commit. Small, focused commits are much easier to review and to undo.

First-time setup and a first repository

git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"
git config --global init.defaultBranch main   # name of the first branch in new repos

mkdir shop-api && cd shop-api
git init                       # creates the hidden .git folder
echo "# Shop API" > README.md
git status                     # README.md is untracked
git add README.md              # stage it
git commit -m "Add README"     # save a snapshot
git log --oneline              # e.g. 3f9c2ab Add README

Depending on your Git version, git init may call the first branch master. Setting init.defaultBranch to main gives new repositories the same name GitHub uses for new repositories.

Seeing what changed

git status                   # which files are changed, staged or untracked
git diff                     # changes NOT yet staged (working directory vs staging area)
git diff --staged            # changes staged for the next commit (staging area vs last commit)
git log --oneline --graph    # short history, with a drawing of branches
git show 3f9c2ab             # one commit: author, date, message and its changes

What a commit really is

A commit stores four things: a snapshot of every tracked file, a pointer to its parent commit (the one before it), the author and time, and the message. Git computes a hash of all this, a long hexadecimal ID such as 3f9c2ab1e0d4... (40 characters with SHA-1, the default). You usually type only the first 7 characters. Because the parent is part of the hash, changing any old commit changes its ID and the ID of every commit after it. This is why history in Git is very hard to tamper with silently.

Good commit messages

• A short subject line, about 50 characters, written as a command: "Fix GST rounding on invoices", not "fixed stuff".
• If needed, a blank line and then a body explaining WHY the change was made, wrapped at about 72 characters.
• One logical change per commit. "Add login page and upgrade database driver" should be two commits.

Ignoring files with .gitignore

Some files must never be committed: installed packages, build output, log files and secrets. List patterns for them in a file named .gitignore at the top of the repository, and git status stops showing them.

# Any file ending in .log, in any folder
*.log
# ...except keep.log (! means "do not ignore")
!keep.log
# A trailing slash matches a directory with this name, at any depth
node_modules/
# A leading slash anchors the pattern to the repository root only
/build
# Local secrets
.env

Common mistakes and how to fix them

• Added a file to .gitignore but Git still tracks it? .gitignore only affects untracked files. Run git rm --cached file to stop tracking it, then commit.
• Staged the wrong file? git restore --staged file takes it out of the staging area and keeps your edits.
• Want to throw away edits to a file? git restore file puts back the last committed version. Careful: those edits are gone.
• Wrong message on the last commit (not pushed yet)? git commit --amend -m "Better message".