Rules to Better GitHub
RuleSummaryIntro
Hold on a second! How would you like to view this content?
Just the title!
A brief blurb!
Gimme everything!
Page Content
Rules to Better GitHub
It is important when working in multiple projects to ensure consistent practices.
Structuring your repositories consistently makes your project feel professional, and makes it easier to work with as it is predictable.
-
- Figure: Bad Example – The folder containing the source code is called ‘trunk’ rather than ‘src’. There is no docs folder containing the important documents as per
Do you review the documentation?
-
- Figure: Good example - All documentation Is in the ‘docs’ folder, samples are in the ‘samples’ folder and all the source code is in the ‘src’ folder
It is important that you know how to use labels for GitHub issues when using an open source project on GitHub.
Managing your labels on GitHub issues will let the community feel professional and make it easier to work with as it is predictable
When you are using an internal project management solution (such as Azure DevOps) for an open source project. It is a good idea to use labels to demonstrate that an issue is being worked on to the community.
This way you can give the community an understanding of the current goals of the project and a higher feeling of interactivity with your development team.
- Bad Example: It is hard to understand what issues are being worked on
- Good Example: It is very simple to understand if an issue has received attention
It is important when creating a new repository, to set it up correctly. Repositories without Descriptions, ReadMe files or licenses do not appear professionally built.
- Figure: Bad Example – Without the correct .gitIgnore, files that should not be included in the repository will be added. Without the correct license, your project will either be under-protected or over-protected
- Figure: Good Example – As well as a good repository name and description, a ReadMe, .gitignore and license will be included in the repository.
