3 ms·
The chunk about `git reset --hard` should be prefixed with a big warning label saying "Don't use this unless you know exactly what you're doing". There are ver
by emeraldd 8y ago
The chunk about `git reset --hard` should be prefixed with a big warning label saying "Don't use this unless you know exactly what you're doing". There are very few legitimate reasons to use `git reset --hard <commit>` in the way that the article describes and even fewer if you're working with remote. Now `git reset` (No commit or --hard) can be useful to retry a screwed staging, but that's about it. As to squashing commits... that's a whole different set of problems when you're dealing with auditors and code review requirements and "public" commits.
- tomc1985 8y agoVery few? I find myself having to use it a lot (usually targetting HEAD or HEAD~1), and actually it's kind of handy for clearing out any cruft when switching between project branches. The important thing to know is that it only acts on files that are added to git, and will pass over any that are not.
- emeraldd 8y agoI've used `reset` that way a few times, but pretty much never `reset --hard` Still, this is not something that should be suggested to someone unfamiliar with git. It's just too easy to screw up your codebase.
- dahart 8y agoYeah, it’s unfortunate that the first two examples, reset --hard, and push -f, are two things you should avoid doing, especially if you’re new to git.