I want to share some Git best practices (and a few of the worst) that I’ve picked up over the years. These are things you probably shouldn’t do unless you really know what you’re doing. I learned most of them the hard way, and not in a fun way either.
The Lesson I’ll Never Forget
During my Computer Science undergrad, I was wrapping up a capstone project with my group. It was finals week, and I had already spent three days straight cramming with no sleep for a brutal calculus test. The capstone was the last class I needed to complete the semester, and I just needed to push through and finish.
Earlier in the evening, everything was fine when I tested my own changes. But when I went back suddenly nothing worked. The project was broken from top to bottom. I was exhausted, stressed, and running on zero sleep. I ended up spending the entire night debugging and going through every change, trying to figure out what had gone wrong. The worst part is that everyone had stacked all their changes in big commits and pushed them directly to main, and none of them were reachable to roll back.
Early the next morning, my husband walked into my office. He took one look at me and asked, “When was the last time you slept?” For context, he’s a full-stack developer with way more experience than I have. He sat down, glanced at my screen, and immediately started asking questions: Why are people pushing to master? Why isn’t the master branch protected? Who thought this was a good idea? It reminded me of the times my mom used to audit my room after I finished my chores as a kid.
After combing through the repo, we finally found the problem. One of my teammates had renamed every single file in the project without updating any of the references, then pushed those changes straight to main with no testing and no communication. To make matters worse, those changes were buried inside massive commits packed with a million other edits, which made tracking down the root cause even harder.
That night was honestly one of the worst days of my student life. But it also ended up being one of the most important. I learned some hard lessons about Git, teamwork, and version control. Since then, I’ve built a list of Git dos and don’ts.
Git DON’Ts
- Don’t push directly to the main branch. Always use branches and protect main.
- Don’t commit secrets, environment variables, or access credentials. Use a secrets manager and add them to .gitignore.
- Don’t commit backups, client data, or database dumps.
- Don’t commit .pem files or sensitive certificates.
- Don’t commit code without testing it first. Just because it runs on your local machine doesn’t mean it works everywhere.
- Don’t commit massive, unrelated changes all at once. Break them down into logical chunks.
- Don’t write commit messages like “fixed stuff” or “changes.” That helps no one later.
- Don’t force-push to shared branches unless you really, really know what you’re doing. It can rewrite history and destroy work.
- Don’t rebase unless you know what you are doing. Rebasing should only be used carefully and with a complete understanding of the risks.
(Fun fact: I once had an AI tell me to rebase… and let’s say that was terrible advice that I didn’t do) - Don’t ignore merge conflicts. Resolve them thoughtfully instead of just hitting “accept everything.”
- Don’t treat Git like a backup tool. It’s for consistency, teamwork, and version control, not just dumping files.
- Don’t keep branches alive forever. Long-lived branches are merge conflict factories waiting to happen.
Git DOs
- Commit often. Small, frequent commits make it easier to track changes, debug, and roll back.
- Write meaningful commit messages. Explain why you made a change, not just what you did.
- Create branches for new features, bug fixes, or experiments. Keep main clean and production-ready.
- Protect the main branch with rules and approvals.
- Make pull requests the standard workflow. Always have a second set of eyes review code.
- Review carefully before merging. Pull requests are where you catch issues early.
- Pull before you push. Keep in sync with the latest changes to avoid conflicts.
- Regularly pull from upstream to keep your branch up to date.
- Tag releases so stable versions are easy to reference or roll back to.
- Use .gitignore wisely to keep junk and sensitive files out of version control.
- Squash commits when it makes sense to clean up history before merging.
- Document setup steps so new contributors can get started without confusion.
Closing Thoughts
Git can be one of the most valuable tools in your toolbox, but only if you use it effectively. A few bad practices can quickly turn into sleepless nights and broken projects, just like I learned the hard way. Following the basics, such as branching, protecting main, writing good commits, and protecting sensitive data, goes a long way to keeping your code and your sanity.
If you have your own Git lessons, good or bad, I’d love to hear them. What’s on your list of dos and don’ts?
Leave a Reply