1

I have a git repository for a library for which I occasionally add new features (or maybe update the existing ones, still same steps).

Whenever I do, I need to do three things:

  • Add the implementation
  • Add tests
  • Update README.md

Now I have two options:

  1. Put them all in one commit:

    • Commit 1: Add FEATURE_NAME + tests + update README.md

  2. Put them in three different commits:

    • Commit 1: Add FEATURE_NAME
    • Commit 2: Add tests for FEATURE_NAME
    • Commit 3: Update README.md for FEATURE_NAME

If I go with the first option, then it will be easier to revert it if I decide my feature is bad, since I only need to deal with one commit.

If I go with the second option, it separates my work into different commits which makes sense.

Which option is better (or maybe there is another way altogether) and why?

Minderov
  • 521
  • 1
  • 5
  • 20
  • 1
    I know it sounds like it's opinion based, but so do questions like "should I just put all my work into a single commit once a month and push it?" while it clearly has an answer that adheres to best practice. – Minderov Jul 28 '18 at 22:30
  • There is a third option: put them in three different commits on a feature branch, then merge that feature branch using `--no-ff`. But I do think this is too opinion based to be appropriate here, sorry. All three forms are commonly used and for all three forms good reasons can be given why they are the most appropriate for some specific project or team. –  Jul 28 '18 at 22:44
  • @hvd thanks! If all the options are commonly used and there is no applicable good practice, then that's a good enough answer for me. I feel like there could be other people googling this because they don't know the right way, and an answer like this (that there is no right way) might be helpful anyway. Or even listing possible good options (I am sure there are many bad ways to do this) with pros and cons. – Minderov Jul 28 '18 at 23:11
  • 2
    You should put everything in the same commit. The tests are linked to the code so there is no reason to commit it after. If you even do TDD, you could even imagine to commit it before. If your feature require to fix other tests, will you commit only your code, breaking the tests. No, so everything needs to be committed in the same time. (And in the TDD spirit, code and test should be considered as same value so it can't be one more important than the other that you should commit first). If there should be multiple commits, that should be cut by doing smaller steps instead – Philippe Jul 29 '18 at 07:57

1 Answers1

3

The first option is the one most often seen out there.
For instance "How git changed my commit behavior"

What does git revert has to do with commit behavior? Well, I always think about what happens if I need to undo a certain change, i.e. revert the corresponding commit. In other words, I consider the “revertability” of commits I make.

In your case, reverting all three coherent and tightly coupled changes is best.

That is in line with the "coherent state of the code" I was advocating for 7 years ago.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Great points, thank you! I like that you mentioned `git bisect` in the linked answer, it certainly seems like all the git tools are made for the first option. – Minderov Jul 29 '18 at 18:32