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

61–70 of 117 posts

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

#61

Post by BugsJustFindMe »

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…

> But the day only has 24 hours

8. The day only has 8 hours. I'm not getting paid for more than that.

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

#62

Post by kevin_b_er »

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…

The way the information is organized can often be just as important. Good data keeping practices can be applied to the history of changes in the software code as well.

The problem is we're still discussing(arguing) over what good practices are.

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

#63

Post by smartbit »

BugsJustFindMe wrote: post #61
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…

> But the day only has 24 hours 8. The day only has 8 hours. I'm not getting paid for more than that.

6. you might get paid for 8 hours, but effectively work 6 hours. The rest of the working hours are for mundane tasks.

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

#65

Post by dkarl »

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.

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

#66

Post by Izkata »

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.

For me, it's useful to peek into the thought process behind the commits if I notice something odd or interesting in the aggregate review. On occasion I end up with a totally different set of comments because I find they'd already tried something I was going to suggest.

More important to me, the "logically split" commits are less useful when hunting down a bug months or years later. They explain the final intent, but not the path to get there, when the path to get there reveals when the bug was actually introduced, and following the thought process using those original commits reveals what the developer was intending instead of just what the end result was.

For example, was the bug introduced in the refactoring/cleanup? This happens a lot, and an earlier state of the code reveals what it should be doing. Was it introduced during initial development? If so, is it just an edge case they didn't think about (because it should have been impossible and a recent change elsewhere made it possible), or is it a remnant of some earlier version of the feature? ..etc

(That remnant-of-an-earlier-version one has actually happened to me and straight removing some code rather than trying to fix it was the correct way to handle it)

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

#67

Post by juped »

fuzzy2 wrote: post #42
juped wrote: post #39

Earlier quoted context omitted.

> 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 tea…

what I mean is, take any arbitrary patch thread off the front page of https://public-inbox.org/git/ and look at how people review them. they reply to the relevant commit. if you reply to the cover letter it's not a code review at all, but a more general comment on the whole branch (e.g., "do we want this feature" or something).

you definitely don't send your branch as a single patch (unless it is small and really is best expressed as a single patch). if you did you would be asked to break it up.

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

#68

Post by 29athrowaway »

This is not a best practice.

Detecting problems is finding a needle in a haystack.

If you want to be efficient at finding the needle in the haystack, you make the haystack smaller.

That is what code review is about. You do not scan the entire source code for defects, only the new code being added.

You can commit often to your own branch, and submit for code review once it's stable.

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

#69

Post by banana_giraffe »

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…

I'm confused: Did you use a revision control system at all? It kinda sounds like your describing the difference between RCS and no RCS.

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

#70

Post by t-writescode »

LAC-Tech wrote: post #29
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 agree 100%. I wish we could use a version control tool that didn't require so much attention. I don't want to read article after article for something that should just get out of my way.

This is honestly where I think good git GUI tools help, and for those I go to Git Extensions, or did until I had to use a Mac for work.

I learned enough using it that I can work through most issues in a regular and natural way nowadays.

Post reply on HN