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

111–117 of 117 posts

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

#111

Post by SergeAx »

Retric wrote: post #104
SergeAx wrote: post #102

Earlier quoted context omitted.

Let's take exactly 10 engineers and let them work on the project for exactly 5 years. That would be roughly 2500 mythical man-months. Let's say 2000 due to vacations, holidays, non-coding tasks, other tasks and Googlesque 20% pet project time. Let's say every engineer produces 100 lines of code including blanks and comments per day and deletes another 50. This is anecdotal, you may check your own numbers. This is +25…

I’ve read codebases that size, ~0.5m LOC is still generally a reasonable thing to read. With that kind of team and progress the majority of code is likely boilerplate. For example you can skim through most UI, ORM, and glue code only really looking for any abnormal parts of it. The goal isn’t to understand every line, the goal is to have a basic map of what’s involved. Even a superficial read likely shows you what pa…

Reading hundreds of thousands LOC does not make any sense for me. When I finish reading I will completely forget what was in the beginning. Heck, I tend to forget my own code in just a couple of months.

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

#112

Post by seba_dos1 »

danny_sf45 wrote: post #45
seba_dos1 wrote: post #24

Earlier quoted context omitted.

Isn't the answer to "is this worth it" quite obvious when doing code reviews? Properly and logically split commits can make it so much easier and more pleasant, and things like "commit often, perfect later" are in my experience less, not more work. The rest seems like a pretty basic set of tips that I mostly learned over the years because I needed them, so it would be definitely nice to read such article several year…

Do people actually do code reviews per commit? I know it's a thing, but in all my years of experience, I haven't met anyone who actually does this. The usual practice is to review all the changes at once (e.g., go to the "Files changed" tab of a PR in GitHub and start reviewing the changes). This, of course, means, that PR are "small". If a PR is too "big" then one politely asks the author to split the PR in many.

Depends on the nature of the particular change, but looking at a merge request commit-by-commit is often much easier to grasp and find potential issues. I usually quickly scan the overall diff first and then proceed to look deeper at each commit.

We're working on FLOSS projects where contributors (internal and external) are asked to split commits logically and that's how they end up in the final history. Most merge requests consist of just a couple of small commits, although sometimes there's a bigger and longer-lived branch where it is easier to just look at the diff as a whole (separate commits still massively improve bisectability though and I can't think of any real downsides of having them retained).

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

#113

Post by CRConrad »

HWR_14 wrote: post #107
lamontcg wrote: post #72

> Once you git push (or in theory someone pulls from your repo, but people who pull from a working repo often deserve what they get) your changes to the authoritative upstream repository or otherwise make the commits or tags publicly visible, you should ideally consider those commits etched in diamond for all eternity. I've broken this rule multiple times per day for the past 10 years. On your own feature branches, r…

I understand using squash. I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" and disagreeing on the value of seeing what happened in parallel?

> I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" [...]?

No, AIUI it's more about keeping logically related commits closer together. And also avoiding or minimizing merge conflicts, if you remember to rebase your feature branch back onto master/main periodically before merging it back in.

(Half expecting a run-in with Cunningham's Law here.)

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

#114

Post by Retric »

SergeAx wrote: post #111
Retric wrote: post #104

Earlier quoted context omitted.

I’ve read codebases that size, ~0.5m LOC is still generally a reasonable thing to read. With that kind of team and progress the majority of code is likely boilerplate. For example you can skim through most UI, ORM, and glue code only really looking for any abnormal parts of it. The goal isn’t to understand every line, the goal is to have a basic map of what’s involved. Even a superficial read likely shows you what pa…

Reading hundreds of thousands LOC does not make any sense for me. When I finish reading I will completely forget what was in the beginning. Heck, I tend to forget my own code in just a couple of months.

It’s not about the low level details it’s what you discover durning the process and building a mental model of the project and the style the code was written in.

Also, memory isn’t just about unprompted recall. If in 8 months you’re looking for how the project generates PDF’s or whatever your not starting from scratch. Sure a full text search will probably bring up a bunch of files but skimming them a second time should look familiar. You may even remember that different sections of code are using two different 3rd party tools because that’s the kind of thing you notice an a first read but might otherwise cause all kinds of shenanigans.

Of course reading takes time, but it’s kind of like negative technical debt. Your prepping so anything else you want to do becomes faster. Asking coworkers about code before they jump ship can clarify stuff in minutes that might take days once they left. Even better you often learn something generally useful on other projects.

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

#115

Post by HWR_14 »

CRConrad wrote: post #113
HWR_14 wrote: post #107

Earlier quoted context omitted.

I understand using squash. I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" and disagreeing on the value of seeing what happened in parallel?

> I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" [...]? No, AIUI it's more about keeping logically related commits closer together. And also avoiding or minimizing merge conflicts, if you remember to rebase your feature branch back onto master/main periodically before merging it back in. (Half expecting a run-in with Cunningham's…

The second example still seems strange - couldn't you just merge the master onto the feature branch to bring it up to date?

I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. But maybe I'm just quite confused.

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

#116

Post by CRConrad »

HWR_14 wrote: post #115
CRConrad wrote: post #113

Earlier quoted context omitted.

> I still never groked the use of rebase. Why not just merge the changes together? Is it just "I want fewer total commits in my history" [...]? No, AIUI it's more about keeping logically related commits closer together. And also avoiding or minimizing merge conflicts, if you remember to rebase your feature branch back onto master/main periodically before merging it back in. (Half expecting a run-in with Cunningham's…

The second example still seems strange - couldn't you just merge the master onto the feature branch to bring it up to date? I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. But maybe I'm just quite confused.

> couldn't you just merge the master onto the feature branch to bring it up to date?

> I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together.

They're related: I meant for the case where you don't (or only lightly) squash your history, so you get several commits from your branch. Maybe if you do regular merges, they're all jumbled up chronologically with whatever else has been merged into master/main in the mean time? Whereas re-base makes it seem that everything in your branch has come "on top of" whatever the current state of m/m is. So when you then later merge your branch back in, all your (possibly compressed into somewhat fewer) commits come as a neat little chain of their own, not interspersed with others?

As I said, I may be wrong as fuck here. Feels intuitively right, but intuition often leads us wrong with software (and other logic), especially such famously non-intuitive stuff as git... But that whole thing of "re-base puts all commits in your branch 'on top of' the branch you base(d?) it on" is how I've understood all descriptions of the "rebase" command I've seen. And it's the only way I can make sense of the whole idea -- because otherwise, as you say, it would be the ssame thing as ordinary merges back-and-forth; no need for a separate name for the same thing. (So if you're going to squash the history of your branch down to a single commit anyway, maybe it makes no difference [except possibly for where in the chronological order it goes]? But don't quote me on that either.)

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

#117

Post by CRConrad »

CRConrad wrote: post #116
HWR_14 wrote: post #115

Earlier quoted context omitted.

The second example still seems strange - couldn't you just merge the master onto the feature branch to bring it up to date? I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. But maybe I'm just quite confused.

> couldn't you just merge the master onto the feature branch to bring it up to date? > I also totally don't get the "closer together" comment. It seems like you are reducing the related commits from 2 to 1, not moving any commits closer together. They're related: I meant for the case where you don't (or only lightly) squash your history, so you get several commits from your branch. Maybe if you do regular merges, the…

FWIW, it seems this[1] (from[2]) confirms my intuition. HTH!

[1]: https://www.cloudsavvyit.com/852/what-is-git-rebase-and-how-...

[2]: https://news.ycombinator.com/item?id=24699804

Post reply on HN