5 ms·
Came out of private mode on my phone to upvote this. One key point I'd like to add though is that you must _always_ run git diff before committing anything. Th
by codyb 9y ago
Came out of private mode on my phone to upvote this.
One key point I'd like to add though is that you must _always_ run git diff before committing anything. There's been enough times where that has saved me from erraneously committing logging statements that are absolutely unnecessary post bug fix.
- davidbanham 9y agoGetting into the habit of always adding via `git add -p` is useful to stop this from happening.
- codyb 9y agoYea commiting by hunks is also super useful. I find a lot of engineers only have a cursory understanding of a lot of git. Rebase vs merge throws a lot of people off and not a lot of people know about git bisect which is just incredibly useful. I think some of it is that people like the graphical nature of things like sourcetree which while offering pretty interfaces don't fully flesh out git. Give me the command line any day.
- concede_pluto 9y agoIt's better to do the big commit and then refactor it. Otherwise you won't have tested whether the hunks depend on each other, which means history littered with broken commits.
- osteele 9y agoYou can also use a different function for temporary debug prints, and a git pre-commit hook that fails if this function is invoked. Pros: Easier to insure that your collaborators follow process; your CI server can run it too. Con: This doesn't catch other issues that a manual `git diff` review will also catch.