3 ms·
> The commit history should be the primary source of truth for what changes have happened. It's just super impractical. The work is discussed / documented in t
by The_Colonel 3y ago
> The commit history should be the primary source of truth for what changes have happened.
It's just super impractical. The work is discussed / documented in the project management systems, I'm not going to copy it extra (from design document, the ticket description, ticket discussion, screenshots) for the SCM. Too much work, too small benefit.
> I've also been at orgs where they've switched from one ticket tracking software to another, and haven't maintained history, or even when they do, the ticket ids and up changing afterward.
I've been in orgs where they've switched SCM and didn't keep history. Neither should happen.
- avgcorrection 3y ago> It's just super impractical. But that’s the whole point of a version control system. That’s all it is for. If that is super impractical then our VCSs (Git and others) must be too impractical to use.
- The_Colonel 3y agoMy team uses git to develop in separate branches and merge into master once ready. It's quite practical for that purpose. We don't use it for documentation of changes made, we have better tools for that.
- avgcorrection 3y ago> We don't use it for documentation of changes made, we have better tools for that. That’s interesting. Is the documentation in the project management system? What tool is that?
- funcDropShadow 3y ago> It's just super impractical. The work is discussed / documented in the project management systems I agree, it is super impractical to have to read the whole discussion again instead of having a comprehensive description of the agreed upon result of that discussion. Therefore, writing good commit messages is really valuable.