Git: The Five Commands That Actually Matter

You Do Not Need Everything

The reason git feels intimidating is that there are roughly 150 git commands and most beginner tutorials list 50 of them as essential. They are not. Five commands handle the daily workflow of every developer I have ever worked with.

status: What Is the State?

git status answers what has changed since my last commit. Run it constantly. Before you commit. After you commit. After you pull.

The output divides into three sections: changes staged for commit, changes not staged, and untracked files. Knowing the difference is 80 percent of git literacy.

add: Pick What to Commit

git add <file> moves a file from not staged to staged. git add . stages everything. Most beginners use git add . exclusively; that bites you when you accidentally include a file you did not mean to (a debug log, node_modules).

The mature habit is git add -p, which goes through changes interactively.

commit: Save the Snapshot

git commit -m "clear message" saves the staged changes. The message matters more than beginners think. Future you will read these messages while debugging at 2am.

Good messages are imperative: Fix tip calculation rounding, not Fixed it. The first word should be a verb. The whole message should fit in 50 characters.

Conventional Commits adds a prefix (feat:, fix:, refactor:) that makes history machine-readable.

push and pull: Sync

git push sends your commits to the remote. git pull grabs anyone elses commits and merges them.

The biggest gotcha: pull can produce a merge conflict. The first time it happens it is terrifying. The fix is just open the file, pick which version to keep, save, and commit again.

The Daily Workflow

# 1. Pull anyone else's changes
git pull

# 2. Make your changes

# 3. See what changed
git status

# 4. Stage what you want to commit
git add <file>

# 5. Commit with a clear message
git commit -m "Fix tip calculation rounding"

# 6. Push
git push

Three More You Will Add Next

1. git checkout -b feature-name - new branch.
2. git log --oneline -20 - see last 20 commits.
3. git diff - see line-by-line changes before staging.

Mistakes to Avoid

• Committing secrets. Never commit API keys or .env files. See GitHub's removal guide.
• Force pushing to main. Do not.
• Vague commit messages. Updates tells future-you nothing.
• Massive commits. One logical change per commit.

Where to Go From Here

Set up a free GitHub account and put one of our mini projects on it. The official Pro Git book is free and excellent. Read chapters 2 and 3.

Branches Without Fear

Branches are the second-biggest concept in git after commits, and the one beginners avoid the longest. The mental model: a branch is a named pointer to a sequence of commits. Creating one costs nothing. Deleting one costs nothing. The cost is purely psychological.

The workflow:

# Create a branch and switch to it
git checkout -b add-tip-rounding

# Make changes, commit normally
git add tipCalculator.js
git commit -m "Round tip to 2 decimals"

# Push the branch
git push -u origin add-tip-rounding

# Switch back to main
git checkout main

Once you are comfortable, the unspoken default is one branch per feature. Open a pull request when ready. Merge when reviewed.

Undo: The Three Commands That Save Lives

Every beginner needs these three. Memorize them:

• git restore <file> - throw away unstaged changes to a file. Useful when you broke something and want to start over.
• git reset --soft HEAD~1 - undo the last commit but keep the changes. Useful when you committed too early.
• git revert <commit> - create a new commit that undoes an old one. Safe to use even after you have pushed. Almost never wrong.

What to avoid until you are sure: git reset --hard (discards changes irreversibly), git push --force (overwrites history for everyone). Both have legitimate uses but the failure mode is "lost work."

Merge Conflicts Are Not Scary

The first merge conflict is the scariest one. After three of them you will be fine. The mechanics:

1. Git stops the merge and marks the conflicted file with <<<<<<, ======, and >>>>>> markers.
2. Open the file. The markers wrap the two competing versions.
3. Decide which version to keep (or merge them). Delete the markers.
4. git add the file and git commit.

That is it. The dramatic name belies a simple workflow. Modern editors (VS Code) make this even easier with conflict-resolution UI buttons.

External References

Two free books that go deeper without overwhelming:

• Pro Git - the official book. Chapters 2-3 are essential; the rest is reference.
• Learn Git Branching - interactive visual tutorial. Best 30 minutes you can spend on git.

Frequently Asked Questions