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

41–50 of 117 posts

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

#41

Post by kossTKR »

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.

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 sufficient, maybe with some randomisation thrown in.

I honestly think the current framework hell we're in has pushed so many hyper-complex best practices that we just waste way too much time on perfecting process over actually coding - tests being one of the paradigms that has gone overboard.

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

#42

Post by fuzzy2 »

juped wrote: post #39
fuzzy2 wrote: post #36

Earlier quoted context omitted.

> You make it significantly less useful by destroying information and creating megadiffs incorporating many different changes. You’ll rarely review single commits anyway. However, I’d rather have a single “giga-commit” instead of dozens of commits that are not correctly divided plus dozens of “remarks from code review” commits because what’s rebase. Many of my colleagues view using Git not as part of their core work…

> You’ll rarely review single commits anyway. This is just because Github and its imitators are bad software - which isn't really git's fault. git and Linux practice only commit-level review. > Many of my colleagues view using Git not as part of their core work but an inconvenient chore. Many people don't care about version history, and ignorance of how git works (or adherence to superstitious rulesets) on the part o…

> git and Linux practice only commit-level review.

I don’t think that’s an accurate way to put it. AFAIK you just send in patch files. They create a single commit, yes, but I see it as equivalent to a PR. The rules of what can be in a single patch could be stricter than typical PRs on other projects, dunno.

> Commit history is just as subject to review as the contents of diffs.

I wish. Maybe I’ll work on a better team on the future.

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

#43

Post by prionassembly »

rendall wrote: post #9

Some great advice. Interesting the explicit references to IRC and email, which is (unfortunately? perhaps?) out of date in these days of github issues and Slack. The original article is 2012 with PRs back to 2016. My current gig is part of a microfrontend/microservices scheme where each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with m…

> each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with more planned. All of these merge into a single web application.

My startup is developing that way, although with more like 9 services owned by 3 developers. (We have no bus factor). Is there anything interesting I can read about your methodologies -- I mean standard references, books, tutorials? (Lerna? Yalc?)

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

#44

Post by cjfd »

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…

You talk about 'long running branch'. I would say that as soon as you have a 'long running branch' you have already lost. Good git practices or bad git practices don't really matter. You will suffer anyway. The only way to make it better is to find a way to do your changes while avoiding the long running branch. I have seen a long running branch that lived some five years or so. It was horrible. And it would have been possible, in this case, to avoid most of the problems using a feature switch instead.

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

#45

Post by danny_sf45 »

seba_dos1 wrote: post #24
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…

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.

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

#46

Post by [deleted] »

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…

[deleted]

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

#48

Post by tremon »

laurent92 wrote: post #34

GDPR and GIT: Should we have personally identifiable usernames/emails in Git?

Yes, because of https://en.wikipedia.org/wiki/Moral_rights_(copyright_law):

> The moral rights include the right of attribution, the right to have a work published anonymously or pseudonymously, and the right to the integrity of the work

Attribution and integrity are guaranteed by Git's committer and hash fields, so it's just complying with the law here. If the artist wants to publish anymously or psuedonymounsly they can do so by choosing the committer name and e-mail appropriately, but to suggest that git is somehow violating the GDPR here is a stretch.

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

#49

Post by tharkun__ »

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, so much this. Same boat here (for long-ish values of "recent").

I can only second all of what you've said. Rebasing and squashing really aren't that hard. If you ask me, selecting who you want to work with simply based on whether they can be taught to rebase and squash is a really good filter. If someone can't manage that, it is very very likely that you won't be happy to talk to them about small commits (easy to PR), good code hygiene and maintainable code, continuous deployments throughout the day (yes, OMG, you have to keep master green at all time, you have to follow up etc.) and a bunch of other things. That's fine by me, but I'd prefer not to work for the same small company as them or at least a few departments away in a larger one.

All of these practices have so many advantages but many people don't or don't want to understand. You can generally teach this to people but it does need everyone to understand and pull on the same string. You can't have a bunch of people in a such a system that just never check the master build after merging.

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

#50

Post by sethammons »

cjfd wrote: post #44
jrockway wrote: post #13

Earlier quoted context omitted.

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…

You talk about 'long running branch'. I would say that as soon as you have a 'long running branch' you have already lost. Good git practices or bad git practices don't really matter. You will suffer anyway. The only way to make it better is to find a way to do your changes while avoiding the long running branch. I have seen a long running branch that lived some five years or so. It was horrible. And it would have bee…

Five years?! Wow. I was thinking that long running was like a week or two.
Post reply on HN