Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sethrobertson.github.io

Post reply on HN
Print view View original

11–20 of 117 posts

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

#11

Post by avar »

cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

You're right, for a lot of people it isn't worth it. The linked article contain way more detail than I daresay the vast majority of users of git need to know about these days.

If you're a programmer who heavily uses it in your workflow you might find this sort of advice useful, but I've helped plenty of programmers with some issue in git that wouldn't have required my help if they had even intermediate knowledge of it.

Does that mean that their time would be best spent knowing more about it? Maybe, but maybe not. In some cases I'd say definitely not. A lot of people are productive with it knowing no more than "git status/add/commit/push/pull".

I've got expert-level knowledge on git, but I use plenty of tools that I've got at best a novice or beginner-level amount of knowledge of. You can't know everything. The tricky part is that until you know something you can't know what you're missing.

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

#12

Post by jackhab »

cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

As someone who also switched from SVN to git many years ago I understand this "is this really worth it" thing. It came to my mind many times in the beginning when I said to myself "do we really need a distributed SCM if everyone are always working against the same server anyways".

But putting git's technical advantages aside, for me, one of its most important values is that it has become de facto industry standard. It's like IP/TCP/UDP protocols which everyone understands be it a tiny IoT device or 10K-core cluster.

With all this enormous amount of programming languages, frameworks and tools we have in the industry it's so nice we've managed to agree, at least, upon one very important element of our work.

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

#13

Post by jrockway »

cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

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.)

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

#14

Post by copirate »

> Personally, I commit early and often and then let the sausage making be seen by all except in the most formal of circumstances. [...] For a less formal usage [...] I let people see what really happened.

> Whenever I pull, under most circumstances I git pull --rebase.

These 2 statements are contradictory. By doing a "pull --rebase" you hide the (maybe important) fact that your commits were written in another context.

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

#15

Post by peakaboo »

cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

Worth it for a few companies, but not for the majority. Most tests are also useless. Going for 100% test coverage is insanity. I think there is a lot of people in tech with autistic personalities who really hate when things are not perfect.

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

#16

Post by tovej »

cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

Some things are more worth it than others, and you can choose how much effort you put in. Small commits are definitely worth it when debugging. I've lost hours, maybe even days because of long commits that were a pain to bisect. The help you get from singling out a commit of 3 changes compared to one with 20 changes is immense.

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

#17

Post by runawaybottle »

peakaboo wrote: post #15
cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

Worth it for a few companies, but not for the majority. Most tests are also useless. Going for 100% test coverage is insanity. I think there is a lot of people in tech with autistic personalities who really hate when things are not perfect.

Couple that with adhd meds which induces a state of compulsiveness where one obsesses and marvels delusionally at their code writing ability.

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

#18

Post by ChrisMarshallNY »

jrockway wrote: post #13
cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

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 differ…

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-...

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

#19

Post by lukicdarkoo »

In my workflow, I typically commit often and use the commits as personal checkpoints. Once a pull request is ready I simply squash the commits and merge. That way, the history in the main branch is clean and I have my checkpoints. I assume that is a typical workflow for many teams.

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

#20

Post by Shacklz »

cjfd wrote: post #4

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…

> I really want to put the 'enough is enough' point before worrying about a good looking commit history.

I see where you're coming from, but I'd like to add a counter-argument to that. I'm currently working on a (mono-) repository with 40-something devs working on it, and we've recently switched from a "everything goes"-commit-history-approach to enforced linear history (while only a handful of people are allowed to directly commit on main-lines without a pull request).

The main reasoning was this: It became almost impossible to understand why a build broke on the mainline by just looking at the commit-history itself. It was always needed to go through build-logs and such to get the picture of the how and why, and often even to get to the 'who', because the commit-history itself was just riddled with merge-commits. For the few devs who took care of that, this was a huge issue, while everyone else was just happily committing away.

So going to the linear-history-approach made "analyze, understand" a breeze, but made "insertion" harder. We had to put in quite a bit of effort to get everyone up to speed (rebase, squash, reset, cherry-pick etc.) and set up some tooling for basic sanity-checks (pre-push-hooks etc.), but it was well-worth it, and a lot of devs were actually happy to be guided through this because for them it's clear that this will also be useful further down the road (in other jobs), not just for the current task at hand.

And at last: It's really not that big of a deal. Just before opening a pull-request (or whatever your equivalent is), have a look through your change-set, run a bunch of commands if necessary, and done. Once you get the hang of it, it's pretty straight forward. It might not be worth it for you personally, but if you work on a repository with many other devs, there might be others who are grateful for that.

Post reply on HN