GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.
Here is a series of rules on how to get the most out of GitHub.
Learn more about Scrum with GitHub.
Everybody strives to be perfect, but mistakes are normal, and it is easy for a developer to skim over errors when they've read their own code code hundreds of times!
Pull requests are the best way to ensure that two sets of eyes see every change - so the responsibility is never solely on the person writing the code.
Consistent naming is important so that users of your GitHub account can easily find what they are looking for and so that you appear professional.
Adding a description to your repositories is essential, so they do not appear blank in the preview on your GitHub profile.
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.
It is important that you, especially a developer, knows how to use labels for GitHub issues when using an open source project on GitHub, as it would help compact issues and make the issue management workflow more efficient. Essentially, having such a predictable workflow will let the community feel professional.
If you accidentally include confidential information in a GitHub Issue - whether it’s a password, API key, or private business details - the obvious thing to do is edit the issue and delete the sensitive content.
But that’s not enough.
GitHub retains a full revision history for issues and comments. This means others can still view older versions and recover the compromised data.
GitHub Issues offer a great way of raising Issues within projects. However, it can be difficult to distinguish whether the Issue is a bug, feature request or just a question. GitHub Issue Templates should be used to help standardize Issues and ensure they have enough information for a developer to start work.
The templates also make it easy for people to write good quality issues, increasing the chance of getting good feedback and suggestions from users.
Let's take a look at how implementing Issue Templates can improve repository backlogs...
Some websites use GitHub to manage their content (e.g. SSW Rules). GitHub makes reviewing changes easy through "Pull Requests".
A Pull Request is a request to make changes to 1 or more files. GitHub provides out of the box functionality for reviewing changes in a pull request. This process is as follows:
As a software developer, you are going to create Pull Requests (PRs) that you want to be easy for others to review and approve. The quality of a Pull Request can vary - from cryptic to well-written.
Including a little bit of context helps your reviewer understand changes quickly so they can review your PR faster and give better suggestions.
There are 2 essential things you should have when writing a Pull Request:
The use of Draft Pull Requests is a handy practice to indicate work in progress promoting early collaboration and continuous feedback. This approach enhances code quality, reduces duplication, and helps to maintain a transparent and efficient development pipeline. Creating Draft Pull Requests will also trigger GitHub Workflows so developers get early feedback on the quality of their changes.
The best way to handle continuous development and deployment is following GitHub Flow. The basic idea is to always deploy from main , and to create a feature branch for every feature. When the feature is complete, it is merged back to main via a pull request, which provides a trigger for other developers to build.
Using this strategy, main is always production-ready and deployable.
Have you ever looked at the list of branches in your repository and not know what they were for?
Consistent naming conventions in source control systems help improve collaboration, clarity, and organization across teams. Using meaningful branch names with PBI numbers enhances traceability and reduces merge debt.
Reviews are a crucial step in the PR process, as they ensure that the code/content is of high quality and adheres to the standards of the project. However, sometimes, developers encounter minor changes that do not require extensive reviews. In such cases, using a rubber stamp label can help expedite the PR approval process.
Pull requests are a fundamental feature of collaborative software development, allowing contributors to propose changes to a project and receive feedback from other developers. When reviewing a pull request, it can be tempting to make additional changes beyond those requested by the PR creator.
Certain projects (E.g. SSW.Rules) allow these additional edits, without the need for extra reviews by someone else. Knowing that, it's crucial to make sure the changes are correct, necessary and beneficial to the project before adding them.
Indentation is a simple but powerful way to make your content easier to scan. When used wisely, it helps readers quickly see structure, hierarchy, and relationships between elements like questions and answers, examples, or nested lists. Overdoing it, however, can make layouts feel uneven or cramped—especially on mobile.
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.
Reading ugly commits is not very pleasant and makes it very confusing when you have to check the commit history.
If a Product Owner sends an email to the development team with a request, that email should be turned into a Github Issue before any work is started or the work is prioritized on the backlog.
Power Automate has a connector to do this automatically when an email arrives in Outlook. It can create a new Github Issue by parsing the From, To, Subject and body of the email.
However, at the moment there is a limitation that it doesn't read inline attachments in emails and therefore you have to create your issues manually in Github.
If all members use 2FA in your organisation, the risk of unauthorised access to your repositories is lower. GitHub organisations can be configured to require all members to use 2FA to join.
When deleting GitHub repositories, it can be hard to tell if you are on a fork or the base repository as the interface is very similar. This can lead to accidental deletions of base repositories.