Too Legit to (Git) Commit?

https://xkcd.com/1597/

Git is wonderful. We’ve said it time and again here at Blue Canvas. But it can be hard.

We were perusing HackerNews the other day and came across a link to this nifty Git cheat sheet. Which led us to another, interactive Git cheat sheet and the above comic (thank you HN commenters!).

As we were glancing through the comments section we came across this not uncommon sentiment:

I think that while Git would be great as a library, as a front-facing program it’s UX could do an improvement: A good UX is simple things should be simple, but complicated things should be possible, but now look at the following “basic” git workflow:… I want git to track this file. Yes, sometimes I need to add certain lines, files, etc. Keep git add, commit, and push. But have a “git update” or something for beginners (and for 99% of use)

The commenter later followed it up with:

Practically, I commit only when it’s ready (building, passes tests). So why would you commit without pushing (unless you’re offline)?

Now we’re not saying this commenter doesn’t have an interesting point - frankly, we’ve been there (we are lazy enough to use a tool like SCM Breeze).

Still, check in early, check in often is a “golden rule of source control”. Why is it? Should it be? How often should a developer commit?

This question is of particular interest to Salesforce developers who have so many stakeholders committing changes to their Orgs: devs, admins, product managers, business analysts etc.

Committing is a Way of Documenting

Having small, frequent commits is one of the key value propositions of Git. However, many feel that it’s annoying to commit frequently. It can take you out of flow which doesn’t feel very good. Still, we think that you should commit often. How often? That’s up to you. We don’t support the need to make onerous commits, but you should make as many as makes sense. Understanding of the value commits provide can make it feel better to stop and just do it.

In the long run, committing small changes saves time. Not unlike unit testing, much of the value associated with it comes in the future. As we learned from Kevin Poorman’s Dreamforce talk, on average 75% of the work on a software project is maintenance work. How many times have you sat digging through Apex code written long ago by someone else, trying to fix some bug that you just introduced. Who added this line? When? And in what context? If only someone had written some documentation!

Well, Git commits can serve as documentation of where something broke and why. Continuous commits allow you to see what someone was thinking, how they arrived at something in natural and telling way. Git commits also serve as useful check points that will help you understand how you broke something. It also helps facilitate better collaboration between colleagues.

As Jeff Atwood presciently said in 2008:

If you learn to check in early and check in often, you’ll have ample time for feedback, integration, and review along the way. And who knows – you might even manage to accrete that pearl of final code that you were looking for, too.

Salesforce Developers and git commit

This comes up from time to time because Salesforce developers have a dual challenge with Git and source control. Even the most diligent teams have to account for declarative changes to their Org. Is this getting checked into source code? And how often? Many teams do daily or weekly backups to Git. This is nice, but it’s kind of like going a whole day or week before making a second commit.

It’s important to get declarative changes at a regular interval just as you would with a change to Apex. Tools like Blue Canvas can help by making automatic commits to your repo for declarative changes. Sign up for our beta to learn more.

‍