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

31–40 of 117 posts

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

#31

Post by juped »

lukicdarkoo wrote: post #25
juped wrote: post #23

Earlier quoted context omitted.

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.

the size of your branch doesn't matter, if it really is logically separable into a lot of changes. what matters is usefulness to the future reader (you, or someone else). lowering the number of commits for its own sake makes things less useful, not more, by destroying useful information.

you are correct to realize that e.g. "my working directory as of this timestamp when i got up from my computer" is not useful information, and should not be published. however, a diff that does too many things at once is also not useful information - you are forcing the reader to separate it themselves, possibly wrongly, every time they read the diff. very few branches in actual practical work are organically one commit long in their most useful expression.

finally, the merge to upstream is useful information, as the only source of a high-level view of the progression towards a release, and if you (i'm only guessing because of the use of the "clean history" shibboleth) avoid actual merges (with merge commits) to upstream, you're destroying important information about the integration work of the project, making the history significantly messier (from the perspective of someone reading it, which is the only perspective that matters).

(at the advanced level of writing-history-for-usefulness, you also realize that random-place-on-master branch starting points are not useful information, and learn where to start them from, but this is low-impact in comparison to not destroying branches. still, learning things like "base a bugfix on the commit that introduced the bug" are real force multipliers.)

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

#32

Post by heurisko »

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 if you're using branches more, then "rebasing" your branch made sense, and the fact that you could "rewrite history", which I remember to some people seemed controversial, but the idea was it was fine, if you kept your branch private, or added caveats.

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

#33

Post by letmeinhere »

> 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 tools to separate paths into their own repositories with intact histories, so I recommend the opposite.

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

#35

Post by Hackbraten »

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.

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

#36

Post by fuzzy2 »

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.

> 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 but an inconvenient chore.

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

#37

Post by marton78 »

ChrisMarshallNY wrote: post #18
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…

The old Perforce Mainline Model[0] prescribes regular merges from the mainline into your working branch, in order to reduce the hit, when you merge back down, into the mainline. Basic common sense, and it also applies to git. With git, those regular up-merges are a lot easier. Personally, I have been using git for years, and have never looked back at Perforce, but learning on more primitive VCSes taught me a discipli…

I agree with this advice in spirit, but I prefer rebasing regularly onto master, rather than merging. Especially in a long lived branch this keeps the list of changes small. Imagine that someone performed a huge refactor in master, which conflicts with some small thing you did in your branch. If doesn't help to have another commit of the huge refactor in your history: the merge commit. I very much prefer to see only the logical changes I did in my branch.

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

#38

Post by ChrisMarshallNY »

marton78 wrote: post #37
ChrisMarshallNY wrote: post #18

Earlier quoted context omitted.

The old Perforce Mainline Model[0] prescribes regular merges from the mainline into your working branch, in order to reduce the hit, when you merge back down, into the mainline. Basic common sense, and it also applies to git. With git, those regular up-merges are a lot easier. Personally, I have been using git for years, and have never looked back at Perforce, but learning on more primitive VCSes taught me a discipli…

I agree with this advice in spirit, but I prefer rebasing regularly onto master, rather than merging. Especially in a long lived branch this keeps the list of changes small. Imagine that someone performed a huge refactor in master, which conflicts with some small thing you did in your branch. If doesn't help to have another commit of the huge refactor in your history: the merge commit. I very much prefer to see only…

That makes sense, as long as the work I do isn't that "huge refactor," for someone else.

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

#39

Post by juped »

fuzzy2 wrote: post #36
juped wrote: post #23

Earlier quoted context omitted.

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.

> 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 of the people who do care provides them cover for trashing the history.

Many people don't care about code quality or maintainability. However, these people are more likely to be prevented from trashing the codebase itself than the ones who don't care about history are from trashing the history.

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

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

#40

Post by sharken »

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.

A set of basic Git commands for everyday use is a good starting point and of course knowing a bit about the staging area and remote/upstream sources as well.

But if you move into the enterprise with multiple releases in active development and multiple teams, then it's hard to keep Git out of the way.

Post reply on HN