Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is your Git commit/push flow?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 201 posts

Re: Ask HN: What is your Git commit/push flow?

#151

Post by erdo »

matticusrex wrote: post #46
jawns wrote: post #9

Here's how I address this problem. When I'm developing, but before I create a PR, I'll create a bunch of stream-of-consciousness commits. This is stuff like "Fix typo" or "Minor formatting changes" mixed in with actual functional changes. Right before I create the PR, or push up a shared branch, I do an interactive rebase (git rebase -i). This allows me to organize my commits. I can squash commits, amend commits, mov…

The only problem I have with this workflow in the command line is that I would like to be able to split changes to the same file across multiple commits. I think some GUI tools enable this, anyone know about it?

Gitx is great for that on a mac, but every time I set up a new MacBook I have to hunt down the latest repo / build. It keeps getting abandoned and then forked and continued, and then abandoned again...

Edit: looks like it's back from the dead again :) https://github.com/gitx/gitx

Re: Ask HN: What is your Git commit/push flow?

#152

Post by SAI_Peregrinus »

Commit often, then interactive rebase, then push to GitHub. Then code review happens, and any comments get addressed with some extra commits.

The annoying thing is that often someone will change CI for some unrelated subsystem (we're in a monorepo) and the way to fix that is "merge master into your branch". Of course I could rebase on top of master before pushing, and I do, but that doesn't work well if the CI change happens while my PR is in review. Then I have to merge master into the PR branch, since people do check branches out to review them sometimes.

Thankfully we squash PRs before merge, so it only ends up with a single commit in Master, but it does mean there's sometimes an intermediate mess.

Re: Ask HN: What is your Git commit/push flow?

#154

Post by spacechild1 »

fatnoah wrote: post #132
jawns wrote: post #9

Here's how I address this problem. When I'm developing, but before I create a PR, I'll create a bunch of stream-of-consciousness commits. This is stuff like "Fix typo" or "Minor formatting changes" mixed in with actual functional changes. Right before I create the PR, or push up a shared branch, I do an interactive rebase (git rebase -i). This allows me to organize my commits. I can squash commits, amend commits, mov…

This is very close to my approach. I work in a private branch and make many commits along the way, but then organize it to tell a coherent story for the actual PR.

I do the same. A clean and logical history helps other people understand your code and might consequently increase the chances of getting it merged.

Re: Ask HN: What is your Git commit/push flow?

#155

Post by michaelsalim »

I commit as soon as a single functionality makes sense as its own. Simple example: If function X uses function A, B and C. I'll commit after finishing A, B, or C. And once X is then, I create a separate commit. I also ensure the code still runs most of the time. How I group them depends on how complicated it is. The more complex, the more commits.

This helps me write code that are more standalone (easier to replace & test). Also helps to clear the cognitive burden when developing larger features. Anything that's committed are pretty much "done". So if I leave any work mid-way, I can simply look at the untracked files to know where I was at.

Then at the end of the work/PR, I go through every changes to make sure everything makes sense.

In practice, this means that the first code I write is often the last I commit (see my simple example above).

Re: Ask HN: What is your Git commit/push flow?

#156

Post by brimble »

twofornone wrote: post #22

>I also push often because I'm forever aware disks can fail. In the 20+ years that I've been using computers, and ≈15 or so that I've been writing software, I've never experienced a drive failure.

About 30 years using computers, a little over 20 being paid to do it. I've had two fail outright (one internal, one external) and a couple others develop errors that I noticed (one because I finally started using ZFS on my bulk-storage machine and it's very good at telling when a drive is misbehaving, the other, SMART caught, years ago) so they had to be replaced. All were spinning rust. Maybe 50 drives total, over my computer-using life, counting those in game consoles and ones in work machines that were assigned to me. Including SSDs. Give or take 10.

With the experience of the last 3 or so years of using ZFS, I'd bet most of my "still working" drives over the years were erroring and losing data by the time I replaced them, and I just didn't know it.

Re: Ask HN: What is your Git commit/push flow?

#157

Post by rootusrootus »

muxator wrote: post #21
rootusrootus wrote: post #5

I follow your flow, and I don't bother squashing my commits. So the repo history has lots of dumb little commits. We use a branch model for features, though, so I can just filter for those merge commits if I want to see granularity at the feature level.

Easier for you. Harder for who reads you history.

Probably. Like I said, though, it's easy to just look at the merge commits and ignore the rest. I don't personally read per-commit history almost ever. If I have to follow someone's train of thought that closely to understand what happened, then 1) the docs suck, 2) or there should have been comments and they are missing, or 3) the story was too complicated.

I will stipulate in advance that this is very much going to vary by project, language, and experience. It is entirely legitimate to have a different point of view ;-).

Post reply on HN