5 ms·

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.

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.

whoomp12342 5y ago
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.
- Quekid5 5y ago
  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.)
  - dijonman2 5y ago
    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.
    - Quekid5 5y ago
      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.
      - whoomp12342 5y ago
        yeah, I mean its situational and sometimes I will do that, but 90% of the time staging does what I need for temp backups
elpakal 5y ago
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.
- gregoryl 5y ago
  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!
  - elpakal 5y ago
    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!
- jsnelgro 5y ago
  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

whoomp12342 5y ago

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.

Quekid5 5y ago
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.)
- dijonman2 5y ago
  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.
  - Quekid5 5y ago
    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.
    - whoomp12342 5y ago
      yeah, I mean its situational and sometimes I will do that, but 90% of the time staging does what I need for temp backups

elpakal 5y ago

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.

gregoryl 5y ago
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!
- elpakal 5y ago
  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!
jsnelgro 5y ago
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