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

81–90 of 115 posts

Re: A Better Git Flow

#81

Post by ninkendo »

dljsjr wrote: post #48
sandgiant wrote: post #36

Earlier quoted context omitted.

Rebase is great, but it's usefulness really depends on the commit history. If your branch consists of 10 commits of trying various things, then the sum of changes in all the commits can easily become significantly larger than the final branch diff. In that case resetting is orders of magnitudes faster than fiddling with rebase.

I would reject a merge from a branch that does more than one thing at a time as you've described during code review. It's okay to have a branch that does a bunch of things at the same time, but come time to merge back to `main` this should be broken up in to several different PR's. I would probably branch off my branch for each logical change I wanted merged and use `rebase -i` to wholesale drop commits that I didn't…

Nothing in sandgiant's post implied that there's more than one thing happening in the branch. Quite the opposite actually, they said that the final diff could be much smaller than the sum of all the small WIP commits along the way. It could be that after hours of digging, you found the real bug was a typo somewhere, and the final diff may be just a 2-line change, where one of the WIP commits was rewriting the whole auth layer because you were chasing a dead-end.

Re: A Better Git Flow

#82

Post by dljsjr »

atq2119 wrote: post #73
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…

Yes, rebase is awesome and every Git user should learn about it. But why not both? When I'm working on a more complex patch series, it's not uncommon for me to have a bunch of already cleaned up, or semi-cleaned up commits on top of the remote branch I'm working against, and then a bunch of random garbage "WIP" commits. Something that often happens is that I `git reset` not to the upstream branch but to my most recen…

Sure. I do that as well. But this article was advocating for using a soft reset to replicate what is ostensibly the built-in fixup mechanisms from interactive rebasing.

Re: A Better Git Flow

#83

Post by dljsjr »

ninkendo wrote: post #81
dljsjr wrote: post #48

Earlier quoted context omitted.

I would reject a merge from a branch that does more than one thing at a time as you've described during code review. It's okay to have a branch that does a bunch of things at the same time, but come time to merge back to `main` this should be broken up in to several different PR's. I would probably branch off my branch for each logical change I wanted merged and use `rebase -i` to wholesale drop commits that I didn't…

Nothing in sandgiant's post implied that there's more than one thing happening in the branch. Quite the opposite actually, they said that the final diff could be much smaller than the sum of all the small WIP commits along the way. It could be that after hours of digging, you found the real bug was a typo somewhere, and the final diff may be just a 2-line change, where one of the WIP commits was rewriting the whole a…

That's exactly what `git commit --fixup` and `git rebase --autosquash` does then.

Re: A Better Git Flow

#84

Post by Double_a_92 »

ninkendo wrote: post #80
Double_a_92 wrote: post #79

Earlier quoted context omitted.

Yeah I also don't see the need for it. Maybe if you often commit completely broken code with meaningless messages... But usually most commits we do at work are still proper little changes (even if it's just 2 lines of a huge feature) with meaningful information in the git message. I would not want to lose that when merging back into the main branch.

> Maybe if you often commit completely broken code with meaningless messages Bingo. I do this all. the. time. I don't want anybody seeing it. I honestly couldn't imagine another way of working... commit early, commit often, I say. Hell, commit on a timer every minute, if that's your thing (I've never done this but totally understand people who do.) Leave the meaningful messages for later when you're actually ready to…

We usually work in a team of 2-3 on the same feature branch, so we can't push half broken things to out teammates.

And the WIP commits can still be done, but locally. Then I clean them up everytime I push to the remote branch, but not when that branch is merged.

Re: A Better Git Flow

#85

Post by ninkendo »

dljsjr wrote: post #83
ninkendo wrote: post #81

Earlier quoted context omitted.

Nothing in sandgiant's post implied that there's more than one thing happening in the branch. Quite the opposite actually, they said that the final diff could be much smaller than the sum of all the small WIP commits along the way. It could be that after hours of digging, you found the real bug was a typo somewhere, and the final diff may be just a 2-line change, where one of the WIP commits was rewriting the whole a…

That's exactly what `git commit --fixup` and `git rebase --autosquash` does then.

Even with autosquash, rebasing has to iterate through each commit individually before creating the final commit. Which means it's touching a bunch of files in your working tree while that's happening, which means build tools like make now have to rebuild them because the timestamps have changed.

What's worse, is if you rebase (say, 20 commits) onto a newer branch than the one you started with, and you have merge conflicts (say, on commit #10), now you might have to fix the conflicts over and over for every commit after the first conflicting one (depending on the contents of the commits). I know there's `git rerere`, but after 16 years using git I've still never learned how it works.

Using reset to squash first, guarantees that you create your single commit first, without dealing with merge conflicts/etc, and then you can rebase that resulting commit once, to deal with conflicts once.

Re: A Better Git Flow

#86

Post by ninkendo »

Double_a_92 wrote: post #84
ninkendo wrote: post #80

Earlier quoted context omitted.

> Maybe if you often commit completely broken code with meaningless messages Bingo. I do this all. the. time. I don't want anybody seeing it. I honestly couldn't imagine another way of working... commit early, commit often, I say. Hell, commit on a timer every minute, if that's your thing (I've never done this but totally understand people who do.) Leave the meaningful messages for later when you're actually ready to…

We usually work in a team of 2-3 on the same feature branch, so we can't push half broken things to out teammates. And the WIP commits can still be done, but locally . Then I clean them up everytime I push to the remote branch, but not when that branch is merged.

Of course I'm talking about local commits, who brought up pushing? I only push when I'm ready to. But turning my local WIPs into something I can push, is most easily done with the reset workflow (but to each their own.)

It occurs to me that people like me might actually be quite rare, who use git almost entirely locally and rarely push. The only times I push are when creating a PR (hence all the resetting and rewriting first), or to back up my WIP work, if it's important. And even then it's to my own fork, and under a branch namespace that nobody would ever confuse with real code that should be reviewed.

Re: A Better Git Flow

#87

Post by benbruscella »

Double_a_92 wrote: post #75
_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.

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

Re: A Better Git Flow

#88

Post by digisign »

ninkendo wrote: post #66
kristaps wrote: post #63

Earlier quoted context omitted.

It's true that messy commits happen, that's why squash is there. Nothing forces you to keep the messy commit messages either - keep the short commit message and make sure it's good, then delete the combined individual commit messages from the long message field, done.

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.)

Not in gitlab at least. Click on squash and you see nothing but the total of the branch difference, the merge req title, and a few lines of boilerplate it adds.

About as easy as it gets. As titles are issue numbers changes are documented automatically.

Re: A Better Git Flow

#89

Post by digisign »

cerved wrote: post #59
_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

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

Re: A Better Git Flow

#90

Post by cerved »

digisign wrote: post #89
cerved wrote: post #59

Earlier quoted context omitted.

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

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

Post reply on HN