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

51–60 of 117 posts

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

#51

Post by vlovich123 »

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.

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.

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

#52

Post by tharkun__ »

jackhab wrote: post #12
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. I…

This just reminded me of when I last didn't use git. It's been so long and really worth it.

It must have been around 2010. I was with a client and they were using SVN in the projects I worked on (and some other obscure - to me - versioning system that they literally had "build masters" for that were the only ones allowed to merge and solve conflicts for the entire company, even though they never ever worked on the code itself). I had been using git before that already for some time and couldn't fathom why anyone would not use that.

They didn't believe my raving about git. Almost needless to say that they were always complaining about merge conflicts, about not being able to do X or Y or Z or that things were slow or error prone (like branches) or that they messed up a conflict resolution upon merging and needed help because they forgot to copy their entire source tree to a different location before doing so etc.

I had zero problems like that because I simply used `git-svn`.

Why is this significant? Because I hear so many people complain about how hard a "trunk based development workflow with rebases" is. Well guess what, that's basically what git-svn is. Nobody in their right mind used SVN any other way but with a single trunk, because branches sucked so much (except for release branches and yes, if you had to bring in something from `trunk` it wasn't just a simply cherry-pick). And because of SVN being what SVN was, before committing to SVN git-svn would simply rebase my work on the current SVN trunk automagically and the issue the commit to SVN. Any conflicts could be solved locally on git and because I had to commit anyway before it could do this rebase. In those two years I had literally one conflict and it was easy to solve, while everyone around me kept having problems. Heck even the feature branches were easy for me, because it's just a different 'trunk' to rebase onto and I actually _could_ cherry pick for them :)

I learned the one lesson I think everyone just has to keep in mind with git: Commit before you do anything else and you won't ever loose work (save bugs in git or you doing stupid low level stuff). You can always just reset back to your commit and redo the botched attempt to resolve conflicts and this time around it should be easier with the knowledge you gained in the first try. That's also why I never use git-stash to move stuff around. There's no commit to go back to if you accidentally did a `git stash pop` instead of `git stash apply`. Heck there was even this one guy who got some rebasing and squashing so wrong that he force pushed a completely different branch onto his branch. "Lost" all of his week's work. He was so so happy when he learned how to find the commit hash for the 'lost work' and that all branches are in git are labels for those commit hashes and we magically brought it all back by reattaching this label to the right commit and force pushing again.

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

#53

Post by Igelau »

heurisko wrote: post #32

I don't know if anyone felt the same way, but I felt I "knew" how to use git before I read tutorials about how to use git. Sometimes I felt tutorials were making it seem harder, more mystical, than it really was, or relied on "marble diagrams" with arrows pointing backwards, which I felt was unintuitive. I had used SVN quite a bit, and found you can use git in pretty much the same way, but branching was easier. And i…

I had a similar feeling of "finally, this makes sense" after enduring ClearCase and SVN for a big chunk of my career.

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

#54

Post by jheriko »

Shacklz wrote: post #20
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…

this is the opposite of my experience at any large workplace.

you can look at merge commits on the history to achieve the same without losing power or data.

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

#55

Post by phone8675309 »

kossTKR wrote: post #41
peakaboo wrote: post #15

Earlier quoted context omitted.

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.

True, i can also get OCD'ey vibes, myself included, i think it comes with mindset one fosters when looking at a screen for long. Same thing can also happen when doing Music or Digital Art, you can fell into a perfectionism loop, where you spend an exponential amount of time on smaller and smaller tasks, that no one will ever care about. For lots of projects writing some quick end-to-end or story based tests is suffic…

A widely used, large framework having really good code coverage is important, especially if not everyone uses all of the framework.

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

#56

Post by phone8675309 »

letmeinhere wrote: post #33

> Does this mean one per product, program, library, class? Only you can say. However, dividing stuff up later is annoying and leads to rewriting public history or duplicative or missing history. Dividing it up correctly beforehand is much better. Got it, simply devise the correct level of modularization for an increasingly complex project at the beginning of time, to avoid annoyances. Easy peasy. /s Git actually has…

> Got it, simply devise the correct level of modularization for an increasingly complex project at the beginning of time, to avoid annoyances. Easy peasy. /s

I know you're being sarcastic, but this is the "you know what every late project has in common - it should have started earlier" observation, just applied to program design. A killer thought terminating cliche.

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

#57

Post by dkubb »

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.

My current team does it, and it is so enjoyable.

We practice atomic commits that change only one thing, and in one way. We separate Fix, Refactor, Change, Add, Move and Remove commits from each other. Our commit summaries begin with those keywords so we can tell what "type" the change is. Each commit must pass CI 100% on it's own.

There are specific characteristics we've noticed. For example, for us, a "pure Refactor" commit either touches code or tests, but not both at the same time. If we touch too much we try to split it, or we call it a Change and it gets even more/different scrutiny.

Reviewing by commit allows me to give my full focus to each without having to keep all state in my head at once. I can step through and understand the series of changes. It's like telling a story, once I've stepped through each commit I am better able to understand the whole picture. If I only look at the summary some of the finer points are missed.

Also we've found we can extract commits more easily and get those merged early while we work on our main branches. If we see a Refactor, we can just do it, extract it and then keep our main PR focused.

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

#58

Post by phone8675309 »

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

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

#59

Post by Dumblydorr »

I'm a beginner at Git. I coded in a hospital system where I was told not to use Git. Upgraded jobs, now I'm using it for the first time.

Wow! What a difference. I have to say the ability to see what I've done over time, to not have endless files labeled with the date and my initials, not having to manually write down what I'm up to...this is heavenly.

My main gripe would be the opaqueness of git. It really wasn't intuitive, I had to use it a few days before the vocabulary made sense, push, pull, commit, add, origin, they didn't logically click for me that fast.

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

#60

Post by bobbylarrybobby »

Dumblydorr wrote: post #59

I'm a beginner at Git. I coded in a hospital system where I was told not to use Git. Upgraded jobs, now I'm using it for the first time. Wow! What a difference. I have to say the ability to see what I've done over time, to not have endless files labeled with the date and my initials, not having to manually write down what I'm up to...this is heavenly. My main gripe would be the opaqueness of git. It really wasn't int…

What was the rationale for not using git?
Post reply on HN