Comment by bastardoperator
4 years ago
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.
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.
2 replies →