For further actions, you may consider blocking this person and/or reporting abuse
Read next
Unlocking VS Code: The Ultimate Cheatsheet for Developers
Mirza Saikat Ahmmed -
Why your brain isn't broken (but documentation might be) - a tab hoarder's musings on learning
Horia Varlan -
A Developerβs Guide to Choosing the Best Notification Platform
Emil Pearce -
12 Useful Developer Tools You Will Wish You Knew Sooner π§βπ»π§
Madza -
Top comments (4)
Nice - more information is always better. The "why" of changes is particularly important for other devs and future you.
One step better is writing your detailed descriptions in the body of commit messages; then it's in the history and directly accessible through whatever interface you use to
git blame
. All of the Git web platforms support this well, including copying the commit body to the description of a pull request.Facebook's tool Phabricator has an excellent article on writing reviewable code + writing good commit messages which goes into more detail.
Completely agree. The article which you mentioned is a great guidance.
Really enjoyed reading this! My team is currently trying to improve our process and I think you had some really good points/ideas that I will bring up to them!
That's great, Connor! All the things in the blog post are based on my practical experience playing as a team.