Hacker News Reader

Comment by bastardoperator | Hacker News Reader

What you're describing is how git should be used. I would add it's important to push your branch to the remote just in case something happens to the local copy. I tend to squash/rebase to get the same type of results, but I can't imagine not saving work regularly or being concerned with the commit history while I'm actively working.

View on HN

I usually commit often locally and push to remote right away. Then when I want to open up my PR, I use `git reset --soft <target>` where target is the local version of the target branch in my PR. That resets all the commits, but keeps all the changes in the staging area, and then I can clean up my history. Then I force push to override what's there.

This works well for my workflow because we squash all commits into target branches and don't really rely on commit history auditing during review. I understand that's not the case everywhere, but works for me.

I never considered soft resets for my work flow (rewrite history with rebase -i). Funny how I use it for other things, but not this. Thanks!

sure thing. I actually just learned about it about a year ago and before then I was rebasing interactively too - this is so much easier!

I just gave this workflow a shot and it was great. Thanks for the tip! Do you use anything for committing more granular chunks of code? I'm just committing groups of files but after reading about magit on other hn threads, I feel like I could do better.

edit: added question

different strokes for different folks. I like to use my staging area as "I want to save this" until I get to a logical stopping point in my work. Then I commit it with its descriptive message. This way I can diff/reset against master while making progress, and show a nice clean progression of my work for who reviews it.

also, sometimes I just lump the whole thing into a PR because there arent more than one logical unit.

You can still get do what you want if you commit every 60 seconds (or whatever). It's just about postponing any and all cleanup activity until you're ready to shared it with reviewers/the world.

(... but of course, by all means do what works for you. Just be aware that you might be missing out on something because you're artificially constraining your workflow.)

A commit every 60s sounds terribly inconvenient unless it’s automatic. I share OP’s workflow patterns and it works for me.

I also don’t use an IDE.

I don't mean 60s literally. I mean arbitrarily small commits at your own convenience.

You don't need to have even remotely working code when you commit, is the point. You just commit whenever. (It's almost like saving files, just commit.)

I think the word 'commit' might have been a mistake, now that I think about it. Maybe 'snapshot' would have been better.

yeah, I mean its situational and sometimes I will do that, but 90% of the time staging does what I need for temp backups

Reply on news.ycombinator.com