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

81–90 of 117 posts

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

#81

Post by Retric »

dkarl wrote: post #65
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 disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.

I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.

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

#82

Post by SergeAx »

I beleive that in feature-branch workflow it is totally okay to rewrite history of the branch before merging it into master. The only case when it is obviously wrong is when several engineers are working on the same feature branch, which is against all methodologies known to me (except the duration of code review, when reviewers may pull the branch to run tests or use IDE on it).

Having atomic semantic idiomatic changes in history beats short term branch immutability with one hand tied.

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

#83

Post by [deleted] »

dkarl wrote: post #65
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 disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.

[deleted]

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

#84

Post by SergeAx »

Retric wrote: post #81
dkarl wrote: post #65

Earlier quoted context omitted.

I disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.

I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.

When your codebase is 5+ years old and was written by 10+ engineers, 2/3 of those are not working here anymore, all you have is commit history linked to task tracking database. So it is naturally the first step of working on a new feature: get to know the subdomain, find corresponding sub-namespaces, look into commit history of those and find related task and specs.

Or you may just punch in a lot of code in hope it will find somehow it's place in codebase and be consistent with other code and readable by your successors and won't break some edge cases not covered by autotests.

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

#86

Post by aelzeiny »

Retric wrote: post #81
dkarl wrote: post #65

Earlier quoted context omitted.

I disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.

I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.

> a sign of poor code quality

Or really complex software. Those of us who work in B2B SaaS products know what it's like to understand what a block of code does, but not comprehend why it was written.

However, I don't disagree with this sentiment. I think what most devs fail to understand about git-history is that it's just another place for sparely populated documentation. Your commit history might be AMAZING, but chances are that nobody knows to look for it. There's just too many places where one has to reiterate intent and purpose (doc-string, inline comments, project specs). It's a lot to keep up with - especially for non-technical folk.

Solutions:

What worked best for my team to was a simple git precommit-hook shell script that just auto-tags the ticket number onto the start of every commit message. So `git blame` just points back to JIRA/Asana/Trello/Whatever you're using to document intent. That way, there's a single source of truth for developer documentation that is accessible by everyone.

At Google if there's something that needs explaining you'll see a tiny-url-link that just points to the Google Doc as an in-line comment (i.e: go/my-project-specification-doc). Commit messages do the same. This saves on copy-pasting multiple lines of purpose on every file and line of code.

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

#87

Post by vngzs »

Retric wrote: post #81
dkarl wrote: post #65

Earlier quoted context omitted.

I disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.

I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.

Ever spend significant time spelunking in the Linux kernel commit history [0]? They have a guide [1] on submitting good patches, and lots of care is taken to commit message quality.

The commits are quite helpful, not just for diagnosing errors but explaining philosophy and reasoning behind code changes [2]. I'm tremendously thankful for the amount of effort those developers put into this, because it helps newcomers come up to speed and follow development. In that kind of codebase, it would be virtually unapproachable otherwise.

[0]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[1]: https://www.kernel.org/doc/html/v4.10/process/submitting-pat...

[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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

#88

Post by Retric »

SergeAx wrote: post #84
Retric wrote: post #81

Earlier quoted context omitted.

I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.

When your codebase is 5+ years old and was written by 10+ engineers, 2/3 of those are not working here anymore, all you have is commit history linked to task tracking database. So it is naturally the first step of working on a new feature: get to know the subdomain, find corresponding sub-namespaces, look into commit history of those and find related task and specs. Or you may just punch in a lot of code in hope it w…

Interesting, I favor reading the entire codebase when possible assuming I am going to be working with it for a few months. I only start really looking at old commits only when I need to edit code that’s particularly brittle or incomprehensible.

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

#89

Post by bcrosby95 »

> If you think about it, movies are made this way. Scenes are shot out of temporal order, multiple times, and different bits are picked from this camera and that camera. Without examining the analogy too closely, this is similar to how different git commits might be viewed. Once you have everything in the “can” (repository) you go back and in post-production, you edit and splice everything together to form individual cuts and scenes, sometimes perhaps even doing some digital editing of the resulting product.

Except the end product is a movie, and my end product is software, not a commit history. If you want to draw an analogy to movies, then rebasing your history would be like movies throwing out raw camera footage because they have the end product. They keep all of the raw footage. They do not throw it out by "rebasing".

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

#90

Post by eikenberry »

mattgreenrocks wrote: post #85

> [don’t] use checkout in file mode What is the alternative? Sometimes I edit a file and don’t need the changes after all.

Many of those misc "do"s/"don't"s read as more good beginner practices than as general lessons. It recommends against that one particularly because it is undoable. Sort of like recommending a *nix newb to map `rm` to `rm -i`.
Post reply on HN