← Back to Git Course | Chapter 8: Best Practices | Lesson 1 of 6

Git Best Practices

Good Git habits -- clear commit messages, focused commits, a shared branching strategy, a maintained .gitignore, and reviewing changes before they're shared -- keep a project's history readable and its collaboration friction-free.

Writing Clear Commit Messages

A good commit message starts with a short, specific summary line written in the imperative mood, like Add or Fix rather than Added or Fixed, and an optional body explaining why the change was made, which future readers rely on far more than the diff itself.

Example: Writing Clear Commit Messages

bash
git commit -m "Fix login button not responding on mobile"

Committing Atomic Changes

An atomic commit contains exactly one logical change -- a single bug fix, a single feature, or a single refactor -- rather than several unrelated edits bundled together, which makes each commit easy to review, revert, or cherry-pick independently of the others.

Example: Committing Atomic Changes

bash
git add login.js
git commit -m "Fix login validation bug"
git add navbar.css
git commit -m "Fix navbar spacing"

Choosing a Branching Strategy

Agreeing on a branching strategy, whether a simple feature-branch workflow or a more structured model like Git-flow, keeps main always deployable, gives every change an isolated branch to be reviewed on, and avoids conflicting work happening directly on the same branch.

Example: Choosing a Branching Strategy

bash
git checkout -b feature/checkout-flow main

Keeping .gitignore Up to Date

A well-maintained .gitignore file, committed early in a project's life, keeps build artifacts, dependency folders, editor settings, and secrets like API keys out of version control entirely, which is far safer and cleaner than committing them and trying to remove them later.

Example: Keeping .gitignore Up to Date

bash
echo "node_modules/\n.env\n*.log" > .gitignore
git add .gitignore
git commit -m "Add gitignore"

Reviewing Before You Commit or Push

Reviewing a diff of staged changes before committing, and reviewing the list of local commits before pushing, catches leftover debug statements, accidental file inclusions, and unclear commit messages while they're still easy to fix, before they become part of shared history.

Example: Reviewing Before You Commit or Push

bash
git diff --staged
git log origin/main..HEAD
🔒

Chapter Quiz — Complete all 6 topics to unlock

0/6 topics done

Complete these topics first:

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.