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

21–30 of 117 posts

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

#21

Post by sharken »

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…

As someone about to move from Mercurial to Git i absolutely agree, even though Git has its quirks, you can always find some help for a specific problem.

Refactoring was mentioned and i think a good Git branching strategy is vital in that regard. If you have multiple branches and merge between them, then refactoring tends to not happen due to developers not wanting to have difficult merges.

The obvious choice is Trunk-based Development, but it's almost a bigger transition than moving to Git.

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

#22

Post by globular-toast »

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…

Like anything, this becomes easier with practice. Once you get into the swing with a good workflow, it no longer requires thought. Make the investment once, reap the rewards later when you have to track down a regression that was introduced some time in the past year.

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

#23

Post by juped »

lukicdarkoo wrote: post #19

In my workflow, I typically commit often and use the commits as personal checkpoints. Once a pull request is ready I simply squash the commits and merge. That way, the history in the main branch is clean and I have my checkpoints. I assume that is a typical workflow for many teams.

Assuming you're referring to something like the github "squash and merge" button, your history is far from "clean". You make it significantly less useful by destroying information and creating megadiffs incorporating many different changes.

Instead, do what you want with personal checkpoints, but refactor them into logical steps before publishing and merging (with a real merge) them.

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

#24

Post by seba_dos1 »

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 years ago to save me some time ;)

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

#25

Post by lukicdarkoo »

juped wrote: post #23
lukicdarkoo wrote: post #19

In my workflow, I typically commit often and use the commits as personal checkpoints. Once a pull request is ready I simply squash the commits and merge. That way, the history in the main branch is clean and I have my checkpoints. I assume that is a typical workflow for many teams.

Assuming you're referring to something like the github "squash and merge" button, your history is far from "clean". You make it significantly less useful by destroying information and creating megadiffs incorporating many different changes. Instead, do what you want with personal checkpoints, but refactor them into logical steps before publishing and merging (with a real merge) them.

The squash and merge button is convenient, but not the only way. As you mentioned, sometimes I do squashing locally into multiple meaningful commits. It's important that my mess doesn't end up in the main branch. Also, another approach would be creating smaller pull requests.

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

#26

Post by juped »

This is still pretty superstitious, even if it's better than a lot of the stuff Github has unfortunately trained people to do. Maybe I'm naive, but I don't think git usage has to be based on superstition and fear. I have never not been able to clear up people's random-internet-post-induced / github-induced confusion in about half an hour of personal communication.

Your goal in making a history is to make a meaningful, useful history that expresses information. I don't think this is hard. I think a lot of people don't want to do it, which isn't my problem (unless I have to work with you), but I also think a lot of people do want to do it and are stymied by posts like this, or by services like Github.

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

#29

Post by LAC-Tech »

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.

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

#30

Post by chiefalchemist »

I use Git the best I can (read: I am by no means Mr Git). I try to read these type of articles and I too often feel inadequate (i.e., there's not enough explanation on what, why, and why that matters). Real life examples would help a lot. Else I have to try to imagine the appropriate situation for each recommendation; and frankly I can't always do that. There are more possible scenarios than I have experiences.

There's got to be a better way. Does learning and/or using have to feel so complicated?

Post reply on HN