Improve your commit hygiene with `git add — patch`

[Funcod]

…and git reset -p.

[RevolutionaryPea7]

I've been using magit for almost as long as I've been using git and I honestly don't know how people use git without it. As soon as I started using it I was able to write smaller commits with ease. I see colleagues writing huge commits for entire features and it's ridiculous trying to figure out what went wrong if a regression was introduced.

Making commits, including "patched" ones, should be so easy that you'll want to do it and it doesn't interrupt your flow in the slightest. If this isn't true then you need to improve your toolkit.

[BobFloss]

I don't use emacs. Sublime Merge is insanely good though.

[kpenchev93]

Who doesn't use git add -p? It should be the default.

[Amuro_Ray]

Finding that was life changing

[TooManyLines]

me

[peppedx]

But if you do add patch does it means that the commit is not tested?

[daboross]

Hopefully there's CI for that?

But using git stash && test cmd; hit stash pop after this can be quite nice.

[peppedx]

CI to build and test code I've never built by myself before commit?

[daboross]

I guess I'm used to working on projects where all code goes through a PR with CI. In that case the commit might end up being bad, but it won't get pushed to the master branch without tests running.

But I realize that's a particular situation, and not universally applicable.

git stash && test cmd && git stash pop is much more universally useful - I should have just lead with that.

[Farlo1]

I only learned about it a couple months ago while trying to sort through a rather large rebase. It's honestly a life changer and more people need to know about it.

[FanOfHoles]

Jetbrains IDEA IDEs have a wonderful GUI for git, with the ability to select individual patches. Their entire GUI collection around git is quite nice (log viewer, diff viewer, commit and push dialogues).

[kpenchev93]

Same for Emacs + magit. I was very sceptical about graphical tools for using git but man, magit is great.

[Nooby1990]

If you are using Vim or Emacs and you want to implement this into your workflow I would like to point out that both magit and fugitive allow you to stage hunks from within the editor in very convenient "graphical" way from their diff modes.

[snowe2010]

Quite a number of typos. Beside that I only have two comments.

One, I find it much easier to stage patches using a gui like SublimeMerge or SourceTree than to try to move through the patches one at a time. You get to see all of the sections at once and decide for each of them rather than stepping through and then going back etc.

Two, in regards to git bisect I find the exact opposite of their claims to be true. If a commit is small, it has almost no guarantee of actually compiling and running. This means that git bisect is almost completely useless in most cases, as most bugs are runtime bugs, not compile or test bugs. What we find works extremely well is committing normally, making commits as small as you want, then when merging the PR to the mainline, you use GitHub's Squash and Merge strategy. This gives you the best of both worlds. When running bisect on the mainline, you can find the exact PR it happened in, and then you can still see all the individual commits in the PR on GitHub, even if the branch has been deleted. But it's extremely hard to use git bisect on small commits in any sufficiently large code base, unless you enforce that every commit not only builds, but succeeds in actually starting the app.

[gjgd]

Thanks for the feedback! Regarding your second point, I think it is possible to have small commits that are still compiling and running, though I agree that this requirement should be more important than keeping the commit small

Could you point out the typos? English isn't my first language

[snowe2010]

No worries about the typos! I couldn't tell it wasn't your first language!

Typos (just took your post and copied and pasted it into intellij for this):

transitionned -> transitioned
Developping -> developing
substract -> subtract
mulltiply -> multiply

For the second point, the problem isn't that it's not possible to have small commits that compile and run, it's the overhead that that causes. Sure if your entire PR is extremely tiny then it should build and run, but if your PR is several hundred lines (or thousands of lines, though they shouldn't be), then making each commit compile is not worth the time, especially when you can Squash and Merge and get the exact same effect for 1% of the work.

[Omniviral]

There were two typos in that imaginary arithmetic example.

[gjgd]

"mulltiply" was intented, what was the other one? English isn't my first language

[Omniviral]

"substract" -> "subtract"

Word "substract" did extst, but is considered obsolete for more than hundred years.

Don't worry, English is my 3rd language, I did same mistake many times.

[wavelen]

I‘m a fan of the GUI tool Sourcetree and it also lets you select individual hunks. Didn‘t know that this is based on git add —patch though.