3 ms·

Make Atomic Git Commits

11 points by pabs3 4y ago

quantified 4y ago
> Rather, it means that you should be able to describe your changes with a single, meaningful message without trying to tack on additional information about some unrelated work that you did. Another way to define an atomic commit is one that can be reverted without any unwanted side effects or regressions, aside from what you’d expect based on its message. If a commit is removed from your git commit history but doing so removes other legitimate changes, then that commit wasn’t atomic. I _think_ the author means small focused commits? There are no examples, so it's hard to tell. Reverting a commit that some has added tests for later will of course introduce regressions. And removing a commit will always only remove the changes of that commit, I think- what am I missing? Commits need to build, and ideally test, in an atomic unit. I'd rather see changes and the tests that validate these changes in a single commit.
- xmcqdpt2 4y ago
  100%, even if the commit is much larger. Doing a git bisect when the commits are large is not as useful as when they are small because you still need to find the bug within the large commit. However doing a git bisect on a repo where not all commits build or test right is a lot more frustrating.
fwlr 4y ago
The exhortation to do atomic commits is a good one but slightly impractical; for whatever reason, I just don’t often think “I should commit this change” during flow state. I did find a semi-practical way of partially implementing atomic commits anyway: rather than git add all, I git add one file and commit, then repeat. It’s not perfect, you do have to review the diff to check for coupled changes (changing a route on the server and the corresponding call on the client, for example), but it’s often possible to “atomicise” your changes into a half dozen commits.
- mjsir911 4y ago
  I tend to use `git add -p` for exactly this purpose ;-)
  - hoseja 4y ago
    I really hate how there's a smallest possible chunk you can't split any further/do line-by-line commits without a lot of hassle.
  - fwlr 4y ago
    Holy hell I had no idea git had that feature, that’s amazing. You’ve significantly improved my workflow
    - pabs3 4y ago
      Even better is `git gui`, it lets you stage individual line changes.
assbuttbuttass 4y ago
I agree generally, but one thing the author doesn't mention is that it's important to always update unit tests in the same commit that you make a code change. Otherwise it's a lot harder to bisect

11 points by pabs3 4y ago

> Rather, it means that you should be able to describe your changes with a single, meaningful message without trying to tack on additional information about some unrelated work that you did. Another way to define an atomic commit is one that can be reverted without any unwanted side effects or regressions, aside from what you’d expect based on its message. If a commit is removed from your git commit history but doing so removes other legitimate changes, then that commit wasn’t atomic. I _think_ the author means small focused commits? There are no examples, so it's hard to tell. Reverting a commit that some has added tests for later will of course introduce regressions. And removing a commit will always only remove the changes of that commit, I think- what am I missing? Commits need to build, and ideally test, in an atomic unit. I'd rather see changes and the tests that validate these changes in a single commit.

xmcqdpt2 4y ago
100%, even if the commit is much larger. Doing a git bisect when the commits are large is not as useful as when they are small because you still need to find the bug within the large commit. However doing a git bisect on a repo where not all commits build or test right is a lot more frustrating.

fwlr 4y ago

The exhortation to do atomic commits is a good one but slightly impractical; for whatever reason, I just don’t often think “I should commit this change” during flow state. I did find a semi-practical way of partially implementing atomic commits anyway: rather than git add all, I git add one file and commit, then repeat. It’s not perfect, you do have to review the diff to check for coupled changes (changing a route on the server and the corresponding call on the client, for example), but it’s often possible to “atomicise” your changes into a half dozen commits.

mjsir911 4y ago
I tend to use `git add -p` for exactly this purpose ;-)
- hoseja 4y ago
  I really hate how there's a smallest possible chunk you can't split any further/do line-by-line commits without a lot of hassle.
- fwlr 4y ago
  Holy hell I had no idea git had that feature, that’s amazing. You’ve significantly improved my workflow
  - pabs3 4y ago
    Even better is `git gui`, it lets you stage individual line changes.

assbuttbuttass 4y ago

I agree generally, but one thing the author doesn't mention is that it's important to always update unit tests in the same commit that you make a code change. Otherwise it's a lot harder to bisect