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

101–110 of 117 posts

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

#101

Post by dahart »

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 interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using.

Otherwise I totally agree with you; git was designed with rebase use in mind. There’s a misleading meme about rebase being a “lie” that just can’t die soon enough. It’s done more damage than good. The problem is that it’s specious - tempting, persuasive, and easy to believe, even if it’s wrong and/or misguided - and the narrative of rebase being bad is supported and spread by respectable people like SQLite’s author. What some people don’t consider is that the story about rebase being harmful is frequently a sales pitch for a different DVCS entirely - the message isn’t to not rebase, it’s to not use git.

Don’t rebase public/main branches (except in emergencies). Do rebase your local work before push. If using rebase in feature branches, use it (along with communication) in inverse proportion to how many other people are using it, because they have to force pull and so nobody stomps on anyone’s work.

The idea that the exact order of every character typed is sacrosanct and should be immutable is strange. But there is a valid point behind some of the rebase criticism, which is that git does not have the best facilities for controlling how history is presented, and if it did, rebase might not be needed to the same degree that it is now. Some DVCSs are designing ways to have a plumbing history, and a separate porcelain history, to use git terminology. That seems like a genuinely good idea, and maybe in the future git can incorporate something like it.

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

#102

Post by SergeAx »

Retric wrote: post #88
SergeAx wrote: post #84

Earlier quoted context omitted.

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.

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 +250 LOC per week and for our team it means that entire codebase will be 0.5m LOC in 5 years.

I saw a codebase this size once. In 2 years I've read about 1/10 of it.

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

#103

Post by erik_seaberg »

Hackbraten wrote: post #35
fuzzy2 wrote: post #28

I agree with most of TFA. However, I urge everyone to start with a monorepo. Splitting a single project (developed by one team) into multiple repos will seriously slow things down later. I've seen it happen.

It gets really bad when two repositories depend on one another, and you forget to track which commits are meant to work together.

Don’t rely on atomic commits when you don’t have atomic deploys. If X and Y are each running on multiple machines, you must plan for new X interacting with old Y and vice versa, because that is going to happen at least while you are rolling the change out or back. This even goes for a Javascript app talking to backend hosts.

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

#104

Post by Retric »

SergeAx wrote: post #102
Retric wrote: post #88

Earlier quoted context omitted.

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.

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 parts to emulate when you need some of that same boilerplate.

Time wise it’s a good substitute for reading HN etc whisk getting up to speed. Personally, I find it vaguely relaxing so it fills a similar role when you just can’t concentrate on the difficult side of things.

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

#105

Post by lamontcg »

dahart wrote: post #101
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 interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. Otherwise I totally agree with you; git was designed with rebase use in mind. There’s a misleading meme about rebase being a “lie” that just can’t die soon enough. It’s done more damage than good. The problem is that it’s specious - tempting, persuasive, and easy to believe, even if it’s wrong and/or misg…

> I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using.

But "or otherwise make the commits or tags publicly visible" is written very broadly.

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

#106

Post by vlovich123 »

angrais wrote: post #77
vlovich123 wrote: post #51

Earlier quoted context omitted.

When I was at FB, there’s no PR as defined at GitHub. Each independent commit was a separate review. So in that sense, all of the 10s of thousands of engineers at Facebook daily review “PRs” at the commit level.

In that case, where you then recommended to only make one commit? Are there guidelines for the average/ideal commit length? Did this add to extra workload in creating "perfect" commits? Likewise, did this mean that pushing "WIP" commits to remote was rare?

Felt like less workload because each commit had independent feedback that you could address resolve. Then you could push each commit as it was ready (or whichever part of the stack was).

Wip commits we’re often and frequent for CI purposes but as with PRs you don’t want to waste too much review time on WIP unless your asking for some preliminary feedback on a complex change.

Ideal commit length was unchanged to any other commit length you might be expected to do on any other team with good commit hygiene.

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

#107

Post by HWR_14 »

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?

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

#108

Post by AtNightWeCode »

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…

If you work with pull requests, as many companies does, it is essential that things go into separated commits. What junior devs often does is refactor something and then also add functionality in the same commit making it hard to understand if a change is an error in the refactoring or part of the new functionality.

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

#109

Post by mtVessel »

phone8675309 wrote: post #58
mtVessel wrote: post #47

> "...your work will not be lost for at least two weeks unless you really work at it" What happens after two weeks?

git will prune inaccessible objects after 2 weeks by default: https://git-scm.com/docs/git-gc#Documentation/git-gc.txt-gcp...

Thanks. It would have been nice if the author had explained that, instead of you.

Now, when is git-gc run? Of course, it's "[w]hen common porcelain operations that create objects are run".

So, what are common porcelain operation? And which ones create objects? On second thought, never mind. I'll just try not to leave anything inaccessible for more than two weeks.

Post reply on HN