Commit often, perfect later, publish once: Git best practices (2013)

Re:Commit often, perfect later, publish once: Git best pract... by jrockway on Sunday July 04, 2021 @05:17AM (#27728299)

It really depends on the timescale of your changes. Change a few lines in an afternoon? Nobody cares about the history. But if you ever have a long-running branch, you will care about your local history. You'll merge in the main branch, and it will conflict. Someone already renamed the thing that you're renaming in your branch. An auto-formatted changed its mind. The API changed. Some stuff was refactored. The difference between "hmm, annoying" and "I'll just delete this work and start over" after struggling for a week pretty much comes down to the history -- remembering what you did and why, and being able to apply pieces of that relative to the new state of the main branch.

This is one of those insidious things that will only affect you. Nobody else has your working copy, and nobody cares what you do in it. But they will be doing their thing while you do yours, and to thrive in that environment, you can take advantage of tools.

(As for keeping PRs/CLs focused, it is sure nice when you hit some weird bug 3 months later and can identify the candidate commit with a bisect. You don't NEED the history to debug something; just debug it. But it can sure help with the "why" and "how" and get you from debugging to fixing much faster. Bisecting is at the top of our debugging checklist -- do it no matter what once you have a reproduction. It saves so much time that it's not even worth thinking about.)

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by ChrisMarshallNY on Sunday July 04, 2021 @06:07AM (#27728518)

The old Perforce Mainline Model[0] prescribes regular merges from the mainline into your working branch, in order to reduce the hit, when you merge back down, into the mainline.

Basic common sense, and it also applies to git. With git, those regular up-merges are a lot easier.

Personally, I have been using git for years, and have never looked back at Perforce, but learning on more primitive VCSes taught me a disciplined, careful approach.

I did have to “unlearn” a few things (mostly, relaxing, and having more faith in the tool), but the transition has been fairly smooth.

[0] https://www.perforce.com/video-tutorials/vcs/mainline-model-...

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by marton78 on Sunday July 04, 2021 @08:57AM (#27729287)

I agree with this advice in spirit, but I prefer rebasing regularly onto master, rather than merging. Especially in a long lived branch this keeps the list of changes small. Imagine that someone performed a huge refactor in master, which conflicts with some small thing you did in your branch. If doesn't help to have another commit of the huge refactor in your history: the merge commit. I very much prefer to see only the logical changes I did in my branch.

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by ChrisMarshallNY on Sunday July 04, 2021 @09:16AM (#27729400)

That makes sense, as long as the work I do isn't that "huge refactor," for someone else.

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by cjfd on Sunday July 04, 2021 @09:53AM (#27729640)

You talk about 'long running branch'. I would say that as soon as you have a 'long running branch' you have already lost. Good git practices or bad git practices don't really matter. You will suffer anyway. The only way to make it better is to find a way to do your changes while avoiding the long running branch. I have seen a long running branch that lived some five years or so. It was horrible. And it would have been possible, in this case, to avoid most of the problems using a feature switch instead.

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by sethammons on Sunday July 04, 2021 @10:16AM (#27729777)

Five years?! Wow. I was thinking that long running was like a week or two.

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by jollybean on Sunday July 04, 2021 @02:06PM (#27731494)

" Change a few lines in an afternoon? Nobody cares about the history."

If you changed a couple lines of code as part of a module refactor or something i.e. ongoing changes, then sure.

But if you were fixing a bug or doing some very specific thing, those are actually the times where hyper-specific contextual commits are necessary.

Git is this generic tool for which we still have not yet learned all the best practices and idiomatic usages.

Probably there should be a handful of types of commits, not more than 3-5 i.e. 'change' 'bug fix' 'upgrade' 'internal release' 'major release' (these are probably bad examples).

[ Parent | on HN ]