6

When I'm working on a project, I tend to write a lot of code. A lot of code means alot of bugs. If I commit my work early on , I have to edit that commit when I encounter a bug and fix it. This is why I have started to commit at the end of the work on the component I'm working on. This means I could do changes without the head-ache of correcting previous commit.

However, This means I have another head-ache. That is breaking down my work into smaller parts to commit them separately.

MetaFight
  • 11,549
  • 3
  • 44
  • 75
SloppyJoe
  • 207
  • 2
  • 4
  • 2
    possible duplicate of [git / other VCS - how often to commit?](http://programmers.stackexchange.com/questions/110595/git-other-vcs-how-often-to-commit) – gnat Jun 21 '16 at 08:56
  • see also: [What is the benefit of git's two-stage commit process (staging)?](http://programmers.stackexchange.com/questions/69178/what-is-the-benefit-of-gits-two-stage-commit-process-staging) – gnat Jun 21 '16 at 08:58
  • 1
    @gnat No, that isn't a duplicate because I have asked in my question about whether I should commit while still working or commit at the end. The link you posted asks whether one should keep the commit size small or big. Thanks. – SloppyJoe Jun 21 '16 at 08:59
  • Please explain: "I have another head-ache: That is breaking down my work into smaller parts to commit them separately." You should test changed code and commit that. If you change an API yes that could mean a big commit, but normally you break everything up and commit that. – RvdK Jun 21 '16 at 09:02
  • no, it answers the question. The problem you think you're having (commit in progress or at end of work) doesn't really exist, as it is addressed in [another question referred in my second comment](http://programmers.stackexchange.com/questions/322821/when-to-commit-work-in-git?noredirect=1#comment685282_322821) – gnat Jun 21 '16 at 09:03
  • @RvdK , Yes I break down my changes into smaller commits. The main problem with that technique is that it could be a headache to commit smaller parts of code that make sense be together in a commit. – SloppyJoe Jun 21 '16 at 09:04
  • @RvdK , I should have mentioned that the changes made by me are related to each other. – SloppyJoe Jun 21 '16 at 09:07
  • 6
    A good rule of thumb is: **Commit when it gives you *value*.** Personally, I commit frequently because it helps me experiment and rollback code to known working states. You may chose to commit for another reason valuable to yourself. – MetaFight Jun 21 '16 at 09:10
  • @MetaFight: If you change an API, then this will probably will be 1 commit to have it compiling. If your working in an API, and changing the font of your application, then these should be different commits. – RvdK Jun 21 '16 at 09:17
  • 8
    Just commit a lot of temporary garbage "Work In Progress" comments into a local branch you'll throw away, and then when you finish implementing whatever you work it on, create a squashed commit in the parent branch with a neat commit message. With Git you can do it both ways. And in a thousand other ways on top of that... – RemcoGerlich Jun 21 '16 at 09:17
  • @MetaFight I agree. Commit when it gives you value. I also commit frequently so I can reset my code to working states. This is especially helpful when having to work with an unreliable API where you have to write a lot of workarounds to get what you need out of it. – Snoop Jun 21 '16 at 10:29
  • 2
    Do not be ashamed of your errors. We all make them. – ctrl-alt-delor Jun 21 '16 at 10:58
  • 1
    Re, "A lot of code means alot of bugs." That's not a hard and fast law. It depends on how you work. – Solomon Slow Jun 21 '16 at 17:14

3 Answers3

10

When working locally commit when:

  • You add a new test case.
  • Your tests pass.
  • You've made any change that works, no matter how insignificant.
    • Renamed a variable? Commit it.
    • Extracted a method? Commit it.
    • Inverted a condition? Commit it.
  • Basically, anytime the code compiles.

Then, prior to pushing it to a shared repository, squash the commits into a single, working change.

The benefits here are that you have a full history of every change you made while working on whatever feature/bug fix you're working on. If you find yourself 3/4 done and realize you need to go back to where you were 1/4 along the way, that's fine because you can. Squashing before you share the code guarantees that each commit in the shared repository represents working code. Anyone could checkout any given commit and still have working code. It's nice to have a clean history when SHTF and someone needs to revert.

RubberDuck
  • 8,911
  • 5
  • 35
  • 44
  • Excellent answer. I would add in a brief aside about feature branches to make it a home run. – Paul Jun 21 '16 at 11:31
4

One principle of Git is commit early, commit often.

You want to commit whenever you made any tangible progress you are not sure you would regret losing suddenly.

If you feel that this results in your git history to end up with too many meaningless commits with vague commit messages, you can squash these commits into one before you push them to the main branch using git rebase.

Philipp
  • 23,166
  • 6
  • 61
  • 67
  • Yep! Normally what I do is commit every time I take a break, and then later massage the commits into something meaningful/legible with `git rebase`. The time spent reworking the commit serves as a kind of code-review, too! – jpaugh Jun 21 '16 at 20:42
2

This is why I have started to commit at the end of the work on the component I'm working on. This means I could do changes without the head-ache of correcting previous commit.

In my opinion, this can be a big mistake if you are working in a team. It's a particularly big mistake when one works part time on task A, part time on task B, part time on task C, etc. (my life), while the rest of the team is blazing away. You're likely to get conflicts galore on trying to merge your work into the overall project if you wait a few weeks or longer to ensure your code works perfectly. (Aside: Your code is never perfect.)

It's much better to commit locally extremely often and merge the larger work into your branch somewhat frequently. On a fast-moving project, I commit several times a day and merge once per day, minimum. Frequent merges mean that you can go talk to the person who wrote the code that broke your code and perhaps come to an agreement. Infrequent merges mean that those changes that broke your code are most likely locked in stone.

My first commit with regard to some task is typically pseudo code that compiles (the pseudo code is almost all comments) but that fails every test. When I leave project A to work on project B, I'll commit and merge. When I come back to project A, the first thing I do is to pull the development branch into my local repo and then merge that into my feature branch. As a result I rarely see conflicts.

A lot of code means a lot of bugs.

That's not necessarily true. What is true is that a lot of untested, unreviewed, and sloppily written code means a lot of bugs. That might be okay if what you're writing is code where errors don't have much of a cost (but that also means it doesn't have much value). If you're writing software where errors can cost millions of dollars or even worse can kill, you simply do not want to do that. There are techniques, some old, some very new, that let one write code that is mostly error-free.

David Hammen
  • 8,194
  • 28
  • 37