Git: 8 simple reflexes before pushing code
Pull Request, Merge Request, Peer Review... whatever the name: in the end, you're showing your code to the team. And nobody likes reviewing an incomprehensible diff on a Friday at 5pm (or at any other time).
A few simple reflexes let you push tested, secure, readable code that respects the project's conventions and your teammates' time.
1. Check sensitive files
No appsettings.*.json with an API key or password inside. Even "just for testing", it stays in the Git history. Public projects on GitHub have been hacked because of old commits. .gitignore helps, but always reread your diff.
2. Clean up debug logs
A Console.WriteLine("test") is useless. A LogInformation("token: {jwt}") is dangerous. Clean up before pushing: no noise, no leaks.
3. Care about variable and method names
A temp2 variable or a DoStuff() method helps nobody, even on a Monday morning. Pick precise, explicit names, even for a small fix.
4. Keep the file clean
No double blank lines, no trailing spaces, no broken indentation: it's painful to review and pollutes the diff for nothing. Use Code Cleanup (Visual Studio) so everything is tidy on every save.
5. Care about your commits
update, fix stuff, final V3... that guides nobody. A good commit is clear, useful, and reads like a history.
6. Respect the project's conventions
No giant Utils.cs gathering anything and everything, especially when the project has clear architecture guidelines. Formatting, names, architecture: it's not for show, it's so that in 3 months nobody rages while reading your diff.
7. Test before pushing
Not "it worked on my machine". Really. Run the tests, check the main scenario, take another look at the impacts.
8. Ask yourself THE question
"Would I find this code weird in a colleague's PR?" If the answer is yes: rewrite, isolate, or explain.
Takeaway: take the time to reread before pushing. The quality of a PR is also what makes the quality of a team.
This article comes from one of my LinkedIn posts (in French): join the discussion ↗