Cover Photo by Yancy Min on Unsplash
As I work more and more with git and GitHub I have become really interested in the version control processe...
For further actions, you may consider blocking this person and/or reporting abuse
I tend to do a lot of commits. I try to keep each commit focused on a single task. So, for instance, if I need to add error handling to something and improve the output formatting, that's two commits. I would work on one, commit it when it is working, and then work on the next thing. I feel like a commit should be a single, descriptive line and should describe a single code addition or modification. Just my personal approach.
I do exactly this with an extra constraint which is that I try to leave tests green. It is not always possible, but when it is I feel it helps a lot with code review and with auto-review too.
Oh, and then I sqash it all together just before I merge my topic branch because I commit A LOT.
I bet this works nicely too if you need to roll back to when things were working right if you start to see errors happening.
The first line of my commits describes what the change will be once it's applied, and I try to keep these pretty well defined and under 100 chars or so.
That means there's a nice semantic limit on how much a commit can do, so while a single commit might add 100 media files or even reprettify the whole codebase, I'd split it up if it was doing two things that I couldn't fully describe in two short sentences.
This is a good delineation for when a change is ready for commit. If you describe it simply it is probably too much of a change to the codebase for one commit.
Committing and pushing acts partly as a form of backup for me, but when merging to something like a sprint branch I try to squash those commits so that the history is more about features than tiny changes.
That's usually what ends up happening to me, when my task is really big and there really aren't good intermediate steps that could warrant an actual commit.
If there are good steps in between, I think there are great benefits to be had from concise and short commits, that explain the reasoning of themselves in their long message. I don't know how many times I've done a git blame to find the commit of some piece of code, and then it was made as a side-task of something completely different, and nobody can explain, why the change was made.
I like to treat commits as the end of a task. I split a feature or bugfix into very small, actionable tasks, like creating a new entity,creating or refactoring a function,implementing or updating a new dependency, etc. Each one of those tasks will be a single commit, as it allows me to roll back to any point in time, and this atomicity also helps keep concise and clear commit messages, as only a few lines change, so it's easy to describe what the commit does in a few characters.
Once the feature is done or the bug is fixed, I squash rebase onto dev/master, keeping the feature/hotfix branch for the commits history for faster searching.
I like this. Treating commits like checking off a todo list is an interesting way to look at it. Do you actually list out the things to do somewhere?
I commit every time I made a change and the application is still working properly, that way I can go back to a previous version that is working well if something go wrong.
This pretty much what I do. If I start a task and it breaks everything, then my next commit is when I get it functioning again. Then I push when I have a complete feature. I guess.
I like the idea of creating a safety net in case changes go wrong. Very cool.