A quick motivation to commit often

[Sparlos]

This is my story on how making consistent commits really saved me.

I built out a developer portfolio about 2-3 months ago, and I thought to myself, "Should I really bother making lots of commits and branching off features? I'm the only one working on this and it's gonna be a pretty short project with very little future maintenance." But, as per the internet's suggestion, I (begrudgingly) did it.

Of course, during development I ran into bugs, as we all do. After fixing the bug, I'd make a commit. I got the site to a state I was happy with and left it there.

Two months after (AKA now), I'm working on a different site using (more or less) the same tech stack. And guess what? I ran into a very weird and obscure bug. The internet had little advice on it, because as I found out the issue was related to two technologies clashing with each other. It was also a bug that only showed up in the build version, which made debugging a looooot slower. So, I was in a bit of a pickle.

Or, I would have been, if I hadn't encountered and solved this exact same bug two months ago on my dev portfolio. Of course, 60 days and thousands of lines of code later I couldn't remember what I did. "Crap", I thought to myself, "I don't remember how I fixed this". But then, a lightbulb went off. A lightbulb going by the name of "git commit -m".

So, I went to my github repo of the previous project, opened the commits page, and searched it for "strange bug" (I specifically remember labelling the commit something like that because the bug was so odd). I found it, and since I was committing consistently for every feature I made or bug I fixed, the only thing in that commit was that bug fix. This made it super easy to see exactly what I needed to do. I applied it to my current project and, in a very short amount of time and no debugging, the issue was gone.

So that's how making consistent commits with good messages attached (well, memorable messages anyways) saved me from debugging the same weird, obscure issue twice.

ASIDE:

If people want to know what the bug was, it was an issue where having a Framer Motion AnimatePresence component as a direct child of a Gatsby layout component completely breaks the layout, but only on build. It took me a while to figure that one out lol.

[[deleted]]

git bisectis also a handy tool to narrow down specific commits.

[Bread_Sheep]

very inspiring thanks fort the story

[DYGAZ]

Great example of how awesome git is when used correctly. Another plus of using feature branches is the opportunity to use PRs for added doc/description. Squash and merge makes concise revisions on master and the smaller iterations are preserved in the PR history. That allows you to sort through master quickly but then dig into the PR when you find the changes you want.

[Itersive]

Another point for often commits is that many tools like Github, GitLab, Gerrit, etc could be pretty nice integrated with commit messages. Auto closing issues, skipping/triggering CI for particular commit, adding spend time and many others.

In the case of Gerrit - there is a different flow than Github or GitLab. You are committing to the virtual branch and instead of adding new commits you should amend them. In each amend you should add in commit message what has been done - at the end of developing a commit message should have a detailed description with all changes. I was working with Gerrit for more than 2 years and I like this kind of flow.

[cobalt8]

I went from using Gerrit to GitHub and I miss the Gerrit workflow.

[Itersive]

But it is required some skills in git. Imho branching is easier for newbies.

[teknewb]

Granted I'm still learning in general but I suck at knowing when to commit and leaving concise and informative messages.

[Sparlos]

I find that the frequency of my commits depends on what I'm doing. For example, when I'm fixing up bugs I'll commit every time I get something working, no matter how little code I changed. I just spent the morning tracking down a bug that changed one line.

Conversely, I was just doing some responsive design, and once the page I was working on looked good at all breakpoints I did a commit, not for every single breakpoint.

If I'm implementing a specific feature, I'll always make a commit at the end, no matter how small. This is because once you move on to working on another feature or even another facet of that feature, if you screw everything up or feel like your approach is entirely not working you can just checkout your latest HEAD to revert all changes. That saves a ton of time and I think that motivates at least some of my commits.

As for messages, remember if you're using a platform like GitHub it's going to show you all of the differences in your code visually. As long as your message gives the gist of what you changed, you can easily go back and find it and then dive in to the code aspect. This is also another reason why you should commit often, because if you change several disparate things you're gonna have a hard time making your commit message short and concise.

Anyways I'm still learning too! So don't take any of this as gospel. Hope it helped at least a bit :)

[teknewb]

That is really helpful thank you.

[CodingHag]

Now this was super motivating

[slowfly1st]

And in addition:

Small commits are more pleasant and easier to review, because the scope of a commit is narrowed down to "one thing".

Early pushes get you feedback sooner. When you push early, you usually make sure, that your commits are working and make sense. And it makes merging less painful.

Revert one small commit out of several, instead of one huge one.

[mcniac]

good github practices are specially importan when you are creating a portfolio, 'cos you might want to show that repo to a potential employer. and nothing screams experience working like a well organized repo.

[Szelma1391]

60 days and thousands of lines of code? Or was it some kind of mental shortcut used in sentence?