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

A Better Git Flow

render.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: A Better Git Flow

#51

Post by ninkendo »

_hao wrote: post #6

What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.

I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed commit message is gonna have a ton of messages that look like "Why the hell isn't this compiling?", "wtf?", "FINALLY PASSES!" etc etc etc.

I could avoid creating those commits in the first place, but asking me to only commit my local changes when I have something intelligent to say about them, is a damn near impossibility for me. I basically use git to "save my work" before I try an approach to something. I reset back if it doesn't work out. Sometimes I reset back again, if the approach that didn't work out turned out to be the least worst option. I create commits to experiment with something, so that I can quickly compare back and forth between two approaches. etc. etc. etc.

I would instead say, that if you're only making commits when you have something logical to say, you're probably not using git to its fullest potential. You should really go nuts with it IMO, and only bother to sound intelligent in your commit messages once you're ready to do so, and (most importantly) you should still make commits before that happens. Git's decentralized for a reason, take advantage!

Re: A Better Git Flow

#52

Post by iamed2 »

ninkendo wrote: post #38

Most folks are complaining about `git reset` being more dangerous and to just use `rebase -i` instead. To each their own... I'm one of those weirdos who also uses the `git reset` in their workflow. I prefer it to `rebase -i` because it doesn't mess with my working tree a bunch while it's happening, plus I like to construct brand new logical commits, in order, in the manner described by the article. But this part set…

Yes, this suggestion effectively addresses the biggest problem with the flow described in the linked post. Accidentally clobbering changes in the main branch used to be one of the top sources of bugs when I started at my current job (incidentally, switching to a rebase workflow helped with this, though I'm sure that wasn't the only route we could have taken).

Re: A Better Git Flow

#53

Post by cerved »

ninkendo wrote: post #38

Most folks are complaining about `git reset` being more dangerous and to just use `rebase -i` instead. To each their own... I'm one of those weirdos who also uses the `git reset` in their workflow. I prefer it to `rebase -i` because it doesn't mess with my working tree a bunch while it's happening, plus I like to construct brand new logical commits, in order, in the manner described by the article. But this part set…

the only gotcha with rebase is that it cherry picks commits and so if you do it willy nilly then you can end up introducing changes where you don't expect them and reverting reverts

it's more complicated but vastly more powerful than reset

Re: A Better Git Flow

#54

Post by laserbeam »

jcranmer wrote: post #43
_hao wrote: post #6

What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.

The problem comes when you have a related set of changes where you both want to see how everything eventually fits together and where you still want to keep small "clean logical units." You can see this kind of thing play out frequently in, for example, Linux changesets, where you might have a 24-patch series of changes that need to go in for a feature.

There's no such thing as "clean logical units". There's a product you work on. There are bugs. The prodct needs some features, good UX, performance requirements.

Spending effort on managing git is mental effort you don't spend on solving your actual problems. By far the best experience I've ever hadeith git was: everyone works straight on the dev branch, just rebase, fix your stuff, test often, and if you're doing some multi-day work then sure, branch and think it over then merge.

That's it. That's all you need. I've had a million more problems with every attempt at making this process "clean", or "smart". Dumb was by far more efficient, more enjoyable, helped us find and fix bugs faster, and had the shortest time to market ever.

Re: A Better Git Flow

#55

Post by alunchbox »

I'm surprised no one has mentioned trunk based development yet. Never going back to git flow at a medium/large org again. Merge hell is a nightmare and releases more so.

> When the feature is complete, make a pull request.

gotta love 100 file commits that take a day to review.

Re: A Better Git Flow

#56

Post by cerved »

dljsjr wrote: post #17

The reset part seem superfluous, most of this can be handled via rebasing. In fact, this is exactly what we do at . Much like the thesis of this article, the goal is to have a set of well organized commits so that when it comes time to do a PR review, you have 1-3 logical units of change and it also improves the ability to do reverts. But you can very easily do this just by rebasing instead of resetting and re-commit…

Fix-ups are nice. I developed a script that takes the all staged content and breaks them up into separate fix-ups that fixup the last commit that changed those lines. I find it pretty handy

Re: A Better Git Flow

#57

Post by ninkendo »

cerved wrote: post #53
ninkendo wrote: post #38

Most folks are complaining about `git reset` being more dangerous and to just use `rebase -i` instead. To each their own... I'm one of those weirdos who also uses the `git reset` in their workflow. I prefer it to `rebase -i` because it doesn't mess with my working tree a bunch while it's happening, plus I like to construct brand new logical commits, in order, in the manner described by the article. But this part set…

the only gotcha with rebase is that it cherry picks commits and so if you do it willy nilly then you can end up introducing changes where you don't expect them and reverting reverts it's more complicated but vastly more powerful than reset

My problem with rebasing is that the vast majority of my commits are garbage "WIP" commits, and I want to squash them away anyway.

Squash-rebasing on top of main makes git replay all of those dumb commits, just to squash them, and I have to fix merge conflicts individually, for every commit I don't even care about, before it's done.

I'd much rather soft-reset to the merge-base, make one clean commit, then rebase that one commit, than any of the other approaches.

The typical response people have is that I shouldn't create so many garbage WIP commits, but... that's just not how my brain works. See https://news.ycombinator.com/item?id=30000320

Re: A Better Git Flow

#58

Post by jayd16 »

I hate Perforce (most because of bugs) BUT the in progress CL workflow is better than this.

Git should introduce stages and allow you to have any number of stages. Git should also have some porcelain around stashing all but one stage and restoring all etc etc.

Re: A Better Git Flow

#59

Post by cerved »

_hao wrote: post #6

What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.

What's the benefit of pretending everything happened in one discrete commit? I'm not sure I see the value, only information destroyed

Re: A Better Git Flow

#60

Post by evanrelf »

dljsjr wrote: post #22
okl wrote: post #20

Earlier quoted context omitted.

Right, I don't think rebasing is that daunting if you take a few hours to practice. It's time well spent. Sometimes you can even create empty commits (--allow-empty) up-front (if you already know about all the things that have to be changed) and fill them via fixup/rebase --autosquash

After learning about fixup and squash commits, I started typing `git rebase -i --autosquash` so frequently that I made an alias for it. It has totally changed the way that I work. You get to have the best of both worlds; commit early, commit often but then also having nice and tidy PR's and histories.

You can also enable auto-squash by default:

    git config --global rebase.autoSquash true
Post reply on HN