|
|
|
|
|
by aelzeiny
1817 days ago
|
|
> a sign of poor code quality Or really complex software. Those of us who work in B2B SaaS products know what it's like to understand what a block of code does, but not comprehend why it was written. However, I don't disagree with this sentiment. I think what most devs fail to understand about git-history is that it's just another place for sparely populated documentation. Your commit history might be AMAZING, but chances are that nobody knows to look for it. There's just too many places where one has to reiterate intent and purpose (doc-string, inline comments, project specs). It's a lot to keep up with - especially for non-technical folk. Solutions: What worked best for my team to was a simple git precommit-hook shell script that just auto-tags the ticket number onto the start of every commit message. So `git blame` just points back to JIRA/Asana/Trello/Whatever you're using to document intent. That way, there's a single source of truth for developer documentation that is accessible by everyone. At Google if there's something that needs explaining you'll see a tiny-url-link that just points to the Google Doc as an in-line comment (i.e: go/my-project-specification-doc). Commit messages do the same. This saves on copy-pasting multiple lines of purpose on every file and line of code. |
|