4 ms·
> do people actually find stashing easier than branching? Absolutely. I stash things all the time. I find feature branches only useful for pull requests. My ow
by __david__ 10y ago
> do people actually find stashing easier than branching?
Absolutely. I stash things all the time. I find feature branches only useful for pull requests. My own code never uses feature branches unless I'm unsure of where I'm headed with the feature—I'll need to continually come back to it and build it a little at a time. But that's very rare.
> Right from the man page: "If you mistakenly drop or clear stashes, they cannot be recovered through the normal safety mechanisms."
Then don't ever use those commands. I don't. Checking one of my repos:
$ git stash list | wc -l
46
I just let the stash grow unbounded. Usually it's for cleaning up unfinished features or debugging when manipulating the repo (in which case it gets popped almost immediately). But often I'll just hit a point where I don't care about what I have too much, but I think it might have promise in the future and so I'll just stash and start over. One of the wonderful git commands is "git stash list -p", letting me search the diffs for code I know I've written at some point.
- jakub_g 10y agoOne of the hardest thing about git is the multitude of options and workflows. It makes it powerful but also intimidating for newbies - so many commands and flags! Having several years of git experience, I've set up on the following workflow, which avoids stashing and mixed resets. I think it's quite safe and simple. 1. using feature branches for everything (except when I'm the only developer in a given repo); I have `goto` and `forkto` and aliases for git checkout / git checkout -b 2. frequent, small commits - for backups, and to have "recovery point" for this scenario when you change one line and everything's on fire and you can't find out what's going on for next one hour 3. try to never do partial commits, always commit everything ( git add -A . && git commit ). This teaches you a discipline to do one thing at a time. If you have a sudden need to do something else, git branch, git commit, git checkout previous-branch. Or git commit, continue working, git rebase -i to reorder/squash commits later if needed. 4. for "work in progress, will come back later" commit I have an alias "wip" = "git commit -A . -m 'wip'" 5. for permanently throwing away stuff, "git reset --hard" (used rarely) 6. since I do lots of small commits, at the end of development I clean up with `git rebase -i`, squash stuff, improve commit messages if needed, maybe reorder etc. Due to 2 and 3 I basically don't use stash at all. I think however not everyone is so keen on interactive rebase as much as I do :)
- dahart 10y ago> I find feature branches only useful for pull requests I wasn't super clear in my top post, sorry. Mentioned a couple times in the thread, but as an alternative to a single stash, I would normally commit, not branch. Consider whether a WIP commit is that much easier than a stash, given that a commit is harder to lose. I mentioned branches because that's the alternative to a multi-stash workflow, or to having a large time gap with a lot of work in-between stash & pop. Otherwise, my question is how much harder, really, is git commit & git reset --soft, compared to git stash & git stash pop? > Then don't ever use those commands. I don't. That seems like a great way to use stash safely. A couple others here mentioned using stash as an alternative to git reset. I'm in favor of that kind of stash usage, it's even safer & easer than losing something to a premature reset.
- kccqzy 10y agoI have more than 400 stashes… it turns out it's quite often that I find my current approach completely wrong and want to do a hard reset. But I don't do a hard reset but I stash it so during my next attempt I can still see it.