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

101–110 of 115 posts

Re: A Better Git Flow

#101

Post by musicmatze »

I feel that these "workflow suggestions" are all nice and dandy, but have nothing to do with the real world. The real world looks like this: Create a new branch, make changes, commit, make a PR, commit some more (all without proper commit messages of course), make more fixup commits, and when it gets merged it gets all squashed into one big commit, rebased on master and ff-merged.

This is what the project I was just hired to work on looks like. Result is a linear history, with multi-thousand-line changes in a commit with message "Implement fixes" and a list of "fix bug", "fix more", "format", "change implementation" in the long-form commit message.

People out there do not even know how to work properly with git, I think it is way too much for them when we start telling them how to "workflow" with git. It is sad, but that's what I see.

Re: A Better Git Flow

#102

Post by Double_a_92 »

_hao wrote: post #99
Double_a_92 wrote: post #75

Earlier quoted context omitted.

This does not work well if you have long-lived branches (i.e. weeks) for more substantial features. Completely squashing it would lose all the granular commits and especially their commmit messages, which might be useful for debugging later on.

You are implying the original branch holding that history will be deleted when squashed into a single commit for a PR. That's not the case (granted, that's based on settings on GitHub, Azure DevOps whatever you're using, but the option is there) because in the PR you still see which branch the changes come from. If you're not deleting the branches you're good. Even if you delete the branch when merging I think most P…

Are you sure? My common usecase when debugging something is "Why is this line of code like this, and who might know something about it?". So then I git blame that file and see when exactly that line was modified. If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me. Even if the original branch is still floating around somewhere, that would still be an extra hassle.

Re: A Better Git Flow

#103

Post by _hao »

Double_a_92 wrote: post #102
_hao wrote: post #99

Earlier quoted context omitted.

You are implying the original branch holding that history will be deleted when squashed into a single commit for a PR. That's not the case (granted, that's based on settings on GitHub, Azure DevOps whatever you're using, but the option is there) because in the PR you still see which branch the changes come from. If you're not deleting the branches you're good. Even if you delete the branch when merging I think most P…

Are you sure? My common usecase when debugging something is "Why is this line of code like this, and who might know something about it?". So then I git blame that file and see when exactly that line was modified. If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me. Even if the original branch is still floating around somewhere, that would still be an extr…

> If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me.

Yes, that's true. My original point still stands though. That commit will have a PR associated with it. You can go to it and see the details of all commits that were used for the merge commit that went into master. Not really a lot of extra work to go to the PR if you're investigating that deep.

> Even if the original branch is still floating around somewhere, that would still be an extra hassle.

If the branch deletion setting when merging a PR is selected, then only the origin branch will be deleted. If you're the one doing the PR and you don't delete your local branches you'll be able to see it locally. In the other case where is someone else's then it becomes harder, and I agree it's an extra hassle.

In my work I try to mandate PR's to be as small as possible, but not smaller. Big PR's do happen, but that and resorting to git blame or bisect happens maybe 2-3 times a year. I think the general rules for source control followed by the team are more important than the implementation details and git magic.

Re: A Better Git Flow

#104

Post by Double_a_92 »

benbruscella wrote: post #87
Double_a_92 wrote: post #75

Earlier quoted context omitted.

This does not work well if you have long-lived branches (i.e. weeks) for more substantial features. Completely squashing it would lose all the granular commits and especially their commmit messages, which might be useful for debugging later on.

Cherry pick those commits into another set of PRs

I don't quite follow. E.g. at work with have feature branches with dozens of meaningful commits that we worked like 2-3 weeks on before merging to master. My point was that I don't want to squash the information contained in all those commits.

I assume people here have different workflows, where they work alone on small features for maybe 1-2 days and then just squash all their tiny WIP commits into one?

Re: A Better Git Flow

#105

Post by lamontcg »

This doesn't really have anything to do with the Git Flow model which is all about having multiple long-lived development branches.

As far as the proposal goes, this is a much better way to do it than trying to preserve every mistake you made along the way. I'd prefer to see either this or just the one squashed commit. I'd just argue that maybe if its important to break it up into multiple commits that you might consider that it should also be separate PRs. If it is necessarily so interlinked that you can't produce separate passing PRs then I probably need to wrap my brain around the whole thing at once as well.

Usually my objection is that multiple different concerns need to be done totally separately. I can't think of the last time I really wanted just separate commits and not entirely different PRs.

Re: A Better Git Flow

#106

Post by yencabulator »

laserbeam wrote: post #54
jcranmer wrote: post #43

Earlier quoted context omitted.

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

A clean history of small atomic commits is great for software archeology. That is going to be needed for debugging anything complex enough.

Re: A Better Git Flow

#107

Post by yencabulator »

cerved wrote: post #90
digisign wrote: post #89

Earlier quoted context omitted.

There's much less value in commits where the tests are broken.

not every single commit needs to pass every single test besides CI only needs to test the merge commit

If every commit passes tests, tools like `git bisect` are much more useful.

Re: A Better Git Flow

#108

Post by digisign »

ninkendo wrote: post #97
digisign wrote: post #95

Earlier quoted context omitted.

Recording sensitive information then relying on your perfect performance to remove it is flawed opsec. Not to mention a waste of time, as our great ancestor mentions.

It’s not a career ending thing if somebody saw my commit history. It’s just mildly embarrassing. It’s not a waste of time either… time spent crafting a final commit from the whole change, writing a descriptive commit message, and documenting everything well helps people review it, and that’s time well spent.

Ok, that's one strategy. However, we put that information in our issue tracker, docs, and source code comments, where more people can reach them more easily. Commit msg is PROJ-1234, which gets automatically gets linked to issue with design and comment history and project/product folks can contribute.

Re: A Better Git Flow

#110

Post by ninkendo »

_hao wrote: post #100
ninkendo wrote: post #66

Earlier quoted context omitted.

My point is that I don't want anyone to see my WIP commits in the first place. Squashing only in the end when merging to master means the code reviewers get to see my messy commit history, which is what I'm trying to avoid. (Yes, my commit history is that bad that it's embarrassing. But at least I commit early and often, which has saved my ass more times than I can count.)

Why not create a new branch (let's call it B) from your messy branch (call it A) and squash everything in B before raising a PR from B -> master That will solve your problems if you're the messy type.

Sure, that’s exactly what I’m advocating for? I’m confused.

You said it’s a waste of time to do this and to just squash when merging instead. I’m saying I’d rather squash first so that my PR looks clean and doesn’t contain my WIP commits. Then you respond saying “well you can just squash before your PR then”… are we going in circles?

Post reply on HN