undefined | Better HN

0 pointszwieback4y ago0 comments

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.

0 comments

ninkendo4y ago

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/<bug_number>_unsquashed` or something so that I can dig it up later if need be. I don't push any of my `prprep/` branches.

Double_a_924y ago

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.

ninkendo4y ago

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

Double_a_924y ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

ninkendo4y ago

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

Double_a_924y ago

ninkendo4y ago

> Maybe if you often commit completely broken code with meaningless messages

Double_a_924y ago

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.

1 more reply

j / k navigate · click thread line to collapse