3 ms·
It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with
by dkarl 3y ago
It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.
- mixmastamyk 3y agoWhy not document it then? In a place where everyone can read it, instead of only developers.
- Izkata 3y ago...are you suggesting spending hours searching through documentation, hoping to possibly find something relevant, instead of just being able to run "git blame" to see why a specific line was changed?
- mixmastamyk 3y agoI use blame often to blame. Code tells how, not why—the domain of specs and comments. Commit messages effectively don’t exist for non-developers. I put spec links in doc strings whenever possible. They are accessible to everyone—devs, PMs, SMEs, stakeholders that pay bills, and myself when at a web browser. Searching is not required but even if it was it would be a tiny fraction of “hours.”
- scme0 3y agoBut if you're using pull requests, you can just look up the PR to get the reasoning and details of the squash commit. I would argue that if you need it to be separate commits after merging, you should create separate PRs most of the time.