Incorporate resources on more advanced git/GitHub usage

[NeuroShepherd]

Misc. resources:

1. How to write a git commit (https://cbea.ms/git-commit/)
2. How to write a git issue (https://medium.com/nyc-planning-digital/writing-a-proper-github-issue-97427d62a20f , https://dev.to/opensauced/how-to-write-a-good-issue-tips-for-effective-communication-in-open-source-5443)
3. git branching (https://www.youtube.com/watch?v=e2IbNHi4uCI)
4. git branching strategies (https://www.youtube.com/watch?v=U_IFGpJDbeU)
5. writing pull requests (https://github.blog/developer-skills/github/how-to-write-the-perfect-pull-request/)
6. Quickstart guide for GitHub projects (https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects)

General flow of knowledge one needs:

1. General git knowledge, and connecting to GitHub
2. Writing good git commits
3. Creating Issues on GitHub
4. Creating branches and pushing them to GitHub
5. Opening pull requests
6. Connecting PRs to issues
7. Connecting issues to projects
8. Managing your project boards

[NeuroShepherd]

This should be done in tandem with #30

[NeuroShepherd]

https://www.youtube.com/watch?v=Q1kHG842HoI branching and some gh features

[NeuroShepherd]

More info about purposes of PRs, how to divide them up, and how to review others:

https://graphite.dev/blog/pull-request-best-practices
https://rewind.com/blog/best-practices-for-reviewing-pull-requests-in-github/
https://jimbobbennett.dev/blogs/how-to-review-a-pr/

TL;DR PRs start with having a clearly defined Issue, and the PR addresses the specific issue with code changes. The reviewer of the PR should therefore be working with this context in mind.