I don't know if this is common or not, but I have a really hard time remembering to commit my code. I know commits are supposed to be meaningful and logical chunks of work that tell a story when viewed in aggregate. And yet... I still find myself chugging along until I get ready to get up from coding without having committed anything! My commit is a giant blob with a message like "finished most of the features." Hopefully there is someone out there who is like me. Hopefully this post speaks to that one person who hyperfocuses on a problem and forgets to commit (or move, or eat, or go outside, or speak to other human persons). Because I discovered a solution.
Plan. Your. Commits.
That's it! Mind blown right? Who could have conceived of such genius?! Surely no one has considered envisioning what you are about to do before you do it before now! Shut up, it was a new idea to me. Here's my thought process:
A lot of the tutorials that I've gone through where Git has been included seem to assume you are a pro committer already. They say things like, "There we go, that seems like a good spot for a commit," or "You'll want to commit your work now." This led me to believe that I could just code along and it would be abundantly obvious to me when I should be committing.
However, I have found that if I preselect my checkpoint, I forget less. Saying things like, "I'll commit again after I've finished this function," or "after I get the url routing hooked up" works a lot better. Mostly. The idea is that once I get there, I can commit, come up for air, see where I'm at, and see where I need to go. It also helps me not need to hold everything in my head and helps (some) for if I leave the project alone for a few days and want to come back. More stuff is written down and less is bouncing around in my head.
So, if your commits look like a pile of [rhymes with commit 💩], try writing your commit message (in your head) before you write the code. If you have a better way, OR, if you have other tricks that would help me keep my head on straight in the long run, please share them! I'd love to hear them.
Latest comments (40)
Just what i needed to hear. Cool little productivity hack, Thanks :)
re: "commit cadence" per Jared Knipp -- commits should always make sense when prefixed by (something like) "with this commit (I)". Old dev trick, makes things easy to understand. Consider...
[with this commit I] Patched feature XYZ to disallow access to unregistered users
[with this commit] Feature ABC is complete and ready for testing and staging
Planned commits as discussed, to me, speaks of a narrow view of Git and the underlying technology. Look into rebase+squash patterns as others mentioned. Also know how to stash as well as branch to increase workflow. And most important is local branch squashing for commit and review.
Professionally no team or job in my past would accept a "I'll commit again after I've finished this function" type commit in the stream.
A commit should be a "logical unit of work" (in master) such as a complete feature, fixed bug, RFC commit, etc. However you want to handle that privately and locally feel free, but that type of commit is not welcome in a large project.
Here is why, if you commit at the wrong checkpoints, don't squash and merge in, all that noise to a Sr Dev/CTO (like me) will provide a fragmented diff to perform a code review. Among other long term problems and bad habits for the team
I follow similar patterns as listed but on what I call a "local scratch" branch. I commit often and never (ever) push without reason. Instead I squash down to a new branch (learn rebase) and commit. The single larger commit, in the scope of a large project, is much easier to work with inside a team even if big.
So your thinking is valid, but how and where it applies is important.
The same flow can be accomplished using stashes. Additionally I suggest a GUI for GIT, there are various studies that empirically show that GUI based GIT and visual doff tools improve quality and cut review time. Or put another way, the command line is critical to know, but you will never, ever, read your diff as well in terminal unless you are deranged.
If you don't know what/when to commit presents 2 serious flags professionally. First for the team in not having a git protocol or understanding communicated, aka pending massive fail. Second flag on the person for not grasping fundamental tools. Sorry to be a hard ass, but I am the guy who un-fucks GIT in every company and I would not hesitate to review company GIT protocol. Commit as if there are 1000 people working on the project. The thinking presented here can be dangerous if not used correctly. The range of comments in this thread spans the entire scope of GIT, from "look what I know" to "I have a job, team, and deadlines and don't have time for rookie shit in my master".
If anyone wants to talk serious GIT strategy hit me up, love to talk GIT, so much to learn and share!
I think I was talking about my strategy on what you're calling the "local scratch branch" in this article. I hadn't really considered the larger scale beyond personal projects, but mucking up somebody's Git Repo is one of my huge fears. You've provided a ton of great methodology and mindset tips that really help. I'm definitely getting a GUI and rebasing/squashing my commits before pull request from now on.
Thanks!
Cool, it was hard to not come off as angry programmer. I tried to sell these skills to General Assembly (NYC) re:GIT course and they wanted no part of anything helpful for actual career. I use Tower for GIT, been on it for 8 years, still have command line chops (saved to when shit goes really bad). Ping me on TwitterZ to talk more. I had the same fears on GIT way back and developing a local strategy to look like I know wtf I am doing was key.
If you have the time to plan and edit and massage your commits then you aren't moving fast enough to innovate
Could be. That seems like a bold statement to apply outside of the hotshot startup industry. I tend to prefer a more methodical "slow is smooth and smooth is fast" mindset, but I've also never been on a high speed project so you could be right.
I was being intentionally provocative, apologies, but yes if you have a role where you can find the time to craft your commits to tell a concise story that will serve you and your successors well then you have found a great place to work, if the idea of having the time to do this seems unrealistic then you are either at an early stage start up or you don't have the support from above you need, I'm currently at a start up moving fast on purpose but have also been in roles where the pressure to 'just do it' was at odds to the concept of coding as a craft
I haven't done really well at working on one thing at a time, so by the time I'm ready to commit my work tree tends to be pretty cluttered with changes.
So I always use -p to selectively stage stuff, making multiple commits after everything is done. Even if the same code is touched by multiple unrelated changes (eg. refactoring or code style), I try to edit the diff to make sure each commit only does what it should. And on the reverse side, if an unpushed commit has an error, I'll rebase or amend before pushing.
Being able to juggle multiple change sets locally and organizing stuff before making the final push is really one of the most powerful parts of git.
For a long time I used TFS rather than a git-based repo. It got me into the habit of withholding all my commits until I was ready to check in and commit to an integrated build. That could usually mean days or a week of work, all sitting on my local machine (I tended to check-point it with "shelvesets").
Since I've moved to git, being able to check point locally has got me to cut right down on the amount of time between commits. Now, I try to make a list of things I've got to do, and when I check something off the list, it's a commit and the message is the item I've finished. Usually an hour or two of work at most :)
Commit early, commit often. Like an online CTRL+S
I've been at this for over decade and will readily admit that my most common commit message is WIP. :-)
Super old thread but,
I always write down some relevant thought that may be useful to me when I continue in the future. Like:
"Styling almost done with navbar, just need to adjust margins now" or something like that. These are WIP commits for myself, of course.
Nailed it.
If I want to implement a feature I usually create a new branch and make commits whenever significant changes are made to files that I can group in the same category. So a commit with a message like
Add footeris a part of a branch likecreate-about-page, which is merged withmasterordevupon completion.How do you guys handle commits with changes unrelated to the branch you're working on?
I use stacked git to keep a series of patches going, and then I can separate the idea of committing. I can work on any patch in the series indefinitely, shuffle them around, and when a patch or series of patches becomes ready, cherry pick it into master and push it. It also makes it really easy to keep patches split into small logical pieces, (or to split them, if you didn't in the first place). And it makes it easy to keep things separate in the first place, so when you think "oh, I should have factored out this first...", you pop off your current patch, create a new one to factor it out, then push your patch back on and continue. It's difficult to explain (people often ask "how is this different than plain git") but I find it a nice way to work (nicer than plain git.)
stgit.org/