Being relatively new to Git (a year or so now, as I finally was able to convince my company to use it), I was curious when the "industry standard" was when it came to committing code.
My particular scenario, I have 4 different servers I have to put my code whenever I make changes:
right now, I typically only commit my changes when they're ready for production, simply due to the fact that I often work directly with the CEO of the company, and we'll go back and forth a lot to iron out exactly what he wants.
Is this a common approach, or should I become more granular and commit after each push to DEV?
Ilango Rajagopal
Fullstack Developer
It depends on the situation mostly but it's usually good practice to commit often. Some of the common scenarios where I commit is:
Though I commit often, I don't push the commits until I finish the task or if a colleague's work depends on yours. When I do push my commits, I deploy to a DEV server immediately for testing and changes can be done then and there. We go live every two or three days. This method works for rapidly building features or fixing bugs.
Of course, depending on your situation this can change but committing often is always a good practice because it allows you to keep track of what changes were made when there are lots of commits versus one large commit where you're hunting for the change you made.
Committing often also allows me to experiment with a feature, so even if it doesn't work out, I can roll back easily.