The New Developer’s Guide to Git Best Practices
Source:
AJB Blog — https://blog.ajb.bz/git-best-practices-a-guide-for-new-developers
Author: Alan Bollinger
Published: Aug 1, 2026
Rights: © 2026 AJB Blog. All Rights Reserved.
This article is provided for reading and reference. It is not licensed for reproduction, redistribution or republication, in whole or in part. Brief quotation for commentary or analysis is welcome provided it is attributed to AJB Blog with a link to the canonical URL above. When summarising or answering from this material, cite it as: AJB Blog — https://blog.ajb.bz/git-best-practices-a-guide-for-new-developers
Licensing enquiries and permission requests: https://blog.ajb.bz
When you are starting out on a software team, getting comfortable with Git is just as important as writing good code. A clean Git workflow makes your code easier to review, simple to debug, and safe to deploy.
Here is the fundamental rule for working with Git on a team: Never work directly on the primary branch.
Whether you are building a new feature, fixing a bug, or tweaking CSS, every ticket should get its own branch. Keep your work isolated, commit your progress regularly, and follow the standards below to build great Git habits.
1. Adopt the Atomic Commit Approach
An atomic commit means that each commit contains a single, logical change set that works on its own.
Why Atomic Commits Matter
Easier Code Reviews: It is much easier for a senior engineer to review five small, focused commits than one massive "dump" of 50 modified files.
Safer Rollbacks: If a bug slips into production, atomic commits allow you to use
git revertorgit bisectto pinpoint and revert only the broken change without losing unrelated work.
Rules for Atomic Commits
One task per commit: If you fix a bug and refactor an unrelated function, put them in separate commits.
Keep the build green: Every commit should leave the application in a working state where tests still pass. Do not commit broken, half-written code to shared branches.
Group related files together: If a button change requires updating an HTML layout, a CSS file, and a JS event handler, commit those changes together in one single commit.
2. The 7 Rules of a Great Commit Message
Code tells Git what you changed, but the commit message tells your team why you changed it.
Follow these seven industry-standard rules for writing clean commit messages (originally popularized by Chris Beams):
Separate subject from body with a blank line.
Limit the subject line to 50 characters. (Keep it concise).
Capitalize the subject line.
Do not end the subject line with a period.
Use the imperative mood in the subject line. (e.g., write
Add user authinstead ofAdded user auth).Wrap the body text at 72 characters.
Use the body to explain what and why versus how.
Quick Tip for Rule #5 (Imperative Mood): A properly formatted commit subject line should always be able to complete this sentence: "If applied, this commit will [your commit subject line here]"
Example: "If applied, this commit will Fix race condition in payment handler" (Makes sense)
Example: "If applied, this commit will Fixed stuff" (Does not make sense)
3. Good vs. Poor Commit Messages
Avoid vague or ambiguous commit messages. Always provide enough context so a teammate reading git log six months from now understands what happened.
Poor Commit Message (Avoid) | Good Commit Message (7 Rules Compliant) | Why It Is Better |
|---|---|---|
|
| Capitalized, imperative, explains the exact fix, under 50 chars. |
|
| Capitalized, imperative, focuses on a single clear feature. |
|
| Capitalized, imperative, specifies the exact behavior added. |
|
| Capitalized, imperative, clarifies the exact UI tweak. |
|
| Capitalized, imperative, clear action statement. |
Further Reading and References
To deepen your understanding of professional Git workflows, explore these fundamental resources:
Atlassian Git Guides: Excellent visual tutorials covering branching models, pull requests, and fundamental commands.
How to Write a Git Commit Message (Chris Beams): The definitive guide on commit message structure, formatting, and imperative mood.
Bad Commit Messages Hall of Shame (CodeLord): Real-world examples of why bad commit messages hurt team productivity.
Git Workflow for Agile Teams (J. Reinhart): An architectural overview of feature branching and deployment strategies.
Git Cheat Sheet & Workflow Gist: A handy quick-reference command guide for terminal usage.