Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
cst199220556yHard reset doesn't work for stashes, it's to clear away a dirty working directory.
'git stash clear' is the big brother of drop; it clears all stashes at once. Use carefully. -
oh I meant to say "that you git stash apply'd" sorry.
I didn't know about git stash clear lol, I'm scared of it now -
cst199220556yYou could do the same thing with commits as well, since you can also checkout a commit instead of a branch(detached HEAD), you just make smaller commits as you go along. Then when you're done, just squash your local changes and push.
For me, stashing isn't a part of workflow like for you, so clearing isn't risky; it's more like if I know I don't need any of the stashes I have, I just clear them out.
I use stashing for only one purpose: getting the changes out of my way if I want to checkout to another place.
Why do you not use pop? It's a safety net if you have conflicts; it works the same as apply. It drops if it knows you don't need the changes anymore. -
cst199220556yBTW, run tests before you commit, not after. That mitigates the risk of pushing buggy/untested code. If you do a git push and you have commits already, they'll be pushed. If not, you'll just get 'Everything up to date.'
Related Rants
I love git stash.
It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.
Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.
That tends to be the very nature of refactors, they usually affect different parts of code.
So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".
Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.
Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.
At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.
* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.
with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).
After you finish the refactor, you can decide to squash things with git rebase.
(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)
random
git