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

71–80 of 115 posts

Re: A Better Git Flow

#71

Post by atq2119 »

okl wrote: post #35
dljsjr wrote: post #30

Earlier quoted context omitted.

1. `git rebase -i` to the commit before the one you want to split 2. mark the commit you want to split as an `edit` 3. remove the file(s) you want to edit from the index so that it's part of your working tree 4. use `git add -p` to stage the hunks you want in the first commit (assuming you want to split commits in a single file) or just commit the files you want in the first commit first, second commit second.

> 4. use `git add -p` I strongly recommend tig

+1 for tig, and for the folks that are less TUI-inclined, there's `git gui`; a neat little tool which is far too little known considering that it's part of core Git. One of the nice things about `git gui` is that it has an "amend last commit" mode that makes splitting up a commit trivial (unless the commit also adds or removes files -- in that case, you're going to have to do some more work).

Re: A Better Git Flow

#72

Post by deadbunny »

Rolcol wrote: post #27
ltbarcly3 wrote: post #13

The use of `git reset` is a little silly and is playing with fire for no absolutely no benefit. If you want to follow the pattern described here, create a new branch and do `git checkout the_feature_branch -- $filename` and pull the changes from the branch you did the work in into the new branch, making commits as described in the article. You can even do `git diff --numstat $feature_branch $new_branch` to see what h…

> and is playing with fire for no absolutely no benefit How so? The previous commits are still recoverable from the reflog.

I've found most people can barely use git, yet alone fucking with reflog

Re: A Better Git Flow

#73

Post by atq2119 »

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 recent clean commit, take the resulting changes apart into individual commits (often, some of them will be squash/fixup as I discovered a bug or missing piece of earlier work) and then `git rebase` with `rebase.autosquash` enabled in my global Git config.

Re: A Better Git Flow

#74

Post by krainboltgreene »

I hate to see git guides where they tell the user to make commits that are literally the description of the diff rather than the why of the change.

"Added new styles to navigation"

No duh, that's what the diff shows, but that doesn't tell us why you made the change, and that's the part we're going to struggle to remember in 6 months.

Re: A Better Git Flow

#75

Post by Double_a_92 »

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

Re: A Better Git Flow

#76

Post by Double_a_92 »

danhab99 wrote: post #39

Why do we keep trying to make git "smart"er than it needs to be? Whenever I hear someone complain about git it's 9/10 times because of ignorance, and it's a simple mistake to solve. No amount of tooling or smartening (as this author seemed to be described) is a valid alternative to training and understanding. The consequences of that is that a smarter tool used by dumb people means those people are held back, and mad…

The article isn't proposing to change anything about git, it just shows one way of cleaning up your branches before merging them... which I guess makes people understand git better? The article is nothing groundbreaking, it's just showing how to use git reset, but still.

Re: A Better Git Flow

#77

Post by nhaehnle »

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

> Every PR/commit merged to master should be a clean logical unit.

The issue is one of review scaling. I wrote a blog post about this a while ago[0], but the gist of it is that those clean logical units are often too small for meaningful high-level reviews of more complex work.

With complex features or refactorings, you're often in a situation where those clean logical units allow reviewers to do a good low-level review (do a check for logic corner cases, style issues, etc.) but they don´t allow a high-level review of how all the pieces of the feature work together.

IMHO the most open-source process friendly solution to the issue is to review patch series, where you can review the series as a whole for the big picture, but also dig into individual commits for the details. Building such a patch series requires an approach as described in the article.

(In closed source environments, you may get a good enough approximation of the result with a separate, disciplined software design process.)

[0] http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...

Re: A Better Git Flow

#78

Post by ninkendo »

zwieback wrote: post #67
ninkendo wrote: post #65

Earlier quoted context omitted.

> Why commit at all if you're going to reset? Because committing is useful? It saves my work. I can get to a point where my code finally compiles, make a quick commit, then do some more dangerous refactoring. If something breaks, I can `git diff` to see what changes I've made since it last compiled. I'll turn this around and ask you: Why do you feel like you can only make a commit if you have something that's reviewa…

Oh, I totally agree with all your use cases for committing, I'm just wondering why the reset. I would either go off on another branch to preserve my temporary work and then clean that up and commit or merge to one of the main branches or I would just push all my intermediate work.

The reset is just a straightforward way to squash your work into one commit without much fuss.

A typical workflow for me:

    $ git commit -a -m "WIP" # picture this, but 100 times as I go
    $ git reset $(git merge-base main HEAD) # Reset to the merge-base to avoid reverting upstream work
    $ git diff # Get a nice overview of everything I've changed, to aid in crafting a nice commit message
    $ git add .
    $ git commit # Type up a nice commit message describing the whole change
Contrast this with using `rebase -i` to squash:

    $ git commit -a -m "WIP" # picture this, but 100 times as I go
    $ git rebase -i $(git merge-base origin/main HEAD) # rebase to the merge-base because I don't want to deal with merge conflicts yet
    $ # search/replace 'commit' with 'squash' in a text editor
    $ # save/quit
    $ # get prompted for new commit message, type it out
    $ # save/quit
They both feel like the same amount of typing to me, but `rebase -i` thrashes my working tree around with each commit, which has a habit of confusing my IDE quite a bit and breaking its build cache. Also, I like the `git diff` step in the reset workflow because it gives me a nice reminder of what my change looks like, which helps inform how I should word my commit. So I use reset.

If I want to keep my intermediate work locally for posterity, I usually use `git branch prprep/_unsquashed` or something so that I can dig it up later if need be. I don't push any of my `prprep/` branches.

Re: A Better Git Flow

#79

Post by Double_a_92 »

zwieback wrote: post #67
ninkendo wrote: post #65

Earlier quoted context omitted.

> Why commit at all if you're going to reset? Because committing is useful? It saves my work. I can get to a point where my code finally compiles, make a quick commit, then do some more dangerous refactoring. If something breaks, I can `git diff` to see what changes I've made since it last compiled. I'll turn this around and ask you: Why do you feel like you can only make a commit if you have something that's reviewa…

Oh, I totally agree with all your use cases for committing, I'm just wondering why the reset. I would either go off on another branch to preserve my temporary work and then clean that up and commit or merge to one of the main branches or I would just push all my intermediate work.

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.

Re: A Better Git Flow

#80

Post by ninkendo »

Double_a_92 wrote: post #79
zwieback wrote: post #67

Earlier quoted context omitted.

Oh, I totally agree with all your use cases for committing, I'm just wondering why the reset. I would either go off on another branch to preserve my temporary work and then clean that up and commit or merge to one of the main branches or I would just push all my intermediate work.

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 craft a PR.

Honest question: if you avoid committing code unless it's working and you have a meaningful message to make, what happens if you screw up your editor undo, and you need to go back to where you were 10 minutes ago? This happens all the time for me... I undo a whole bunch and then accidentally type the "z" button into my buffer because I fumbled the keyboard, and now I can't "redo" back again. If I commit early and often, I can recover the work to where it was, even if it's not compiling yet. If I have to wait for my code to be basically "reviewable", I'd be screwed.

Post reply on HN