It's difficult to say how often you should commit - that is often down to the nature of the work you are carrying out. I guess an overarching rule would be "commit when you reach a natural stopping point in your work" but that is subjective and a lot of it depends on the environment you're working in (how big is your team, do you feature branch or commit straight to master, etc...) Moreover, that natural stopping point can be wildly different from ticket to ticket.
My general rule for naming a commit is "Describe what you achieved in the commit". So if I come across a piece of code 5-6 months later and I'm like "WTF is this for?!", I can git blame, check out the commit message and hopefully that will explain why it is there.
For example, my latest commit on one of the projects I'm working on at the moment is: "Add background job to build monthly categories after a MonthlyBudget is created"
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's difficult to say how often you should commit - that is often down to the nature of the work you are carrying out. I guess an overarching rule would be "commit when you reach a natural stopping point in your work" but that is subjective and a lot of it depends on the environment you're working in (how big is your team, do you feature branch or commit straight to master, etc...) Moreover, that natural stopping point can be wildly different from ticket to ticket.
My general rule for naming a commit is "Describe what you achieved in the commit". So if I come across a piece of code 5-6 months later and I'm like "WTF is this for?!", I can git blame, check out the commit message and hopefully that will explain why it is there.
For example, my latest commit on one of the projects I'm working on at the moment is: "Add background job to build monthly categories after a MonthlyBudget is created"