Rules to Better GitHub

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
Rules to Better GitHub

  1. Do you enable pull requests to ensure code is reviewed?

    github-pullrequest-bad-2.png
    Figure: Bad example - Every developer commits to the master branch, code is not reviewed, and code quality is poor
    github-pullrequest-bad-2.png
    Figure: Bad example - Use the out of the box pull requests to ensure all code is reviewed

    ​
    ​​github-pullrequest-1.png
    Figure: Good example - Use the plugin "Reviewable". Reviewable improves pull requests and code reviews with a powerful UI and easy code commenting. ​See the Reviewable icon above
    ​​github-pullrequest-2.png
    Figure: See how easy it is to see the code rejected​
    ​​
    ​

    Read more about Do you enable pull requests to ensure code is reviewed?

  2. Do you know how to name a GitHub Repository?

    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.

    Figure: Bad example – Repository names are not consistently formatted
    Figure: OK example – Repositories are following the lower-cased hyphenated format that is common for open source projects
    Figure: ​​​Good example – Repository names are name-spaced in the format [CompanyName].[ProjectName]
    ​
    Read more about Do you know how to name a GitHub Repository?

  3. Do you know how to structure a project for 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 – T​he 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
    Read more about Do you know how to structure a project for GitHub?

  4. Do you know the correct license to use for Open Source software?

    More and more projects are being created as Open Source. However just because you’re created an open source project doesn’t mean you give everything in your cookie jar away. You should only release your code subject to a licence agreement. A common confusion when putting projects onto Open Source platforms like GitHub is ‘What License Should I Use?”. We have our own opinions but we aren’t lawyers so if you want to know what’s best for you speak with your lawyer.

    Figure: Bad Example - No License -​ Generally speaking, the absence of a license means that default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. For more information read http://choosealicense.com/no-license/
    Figure: Good Example - GPL License – For projects where you want consumers of your code to share their changes. Anyone who distributes your code or a derivative of your code must make the source available under the same terms. Warning: Consider carefully before using on components to be used in commercial applications due to the CopyLeft requirement. Used by Linux, Git, WordPress -​ GNU General Public License on Wikipedia
    Figure: Good Example - MIT License - for projects where you are happy for people to do anything with your code. Use for .Net core, jQuery and Node.js - MIT License on Wikipedia
    Figure: Good Example – Apache License - for projects where you require attribution. Microsoft use the Apache license for MVC, EntityFramework, SignalR and Roslyn - Apache License on Wikipedia - Used for all SSW Open Source Projects. 
    Read more about Do you know the correct license to use for Open Source software?

  5. Do you know to mention someone with a @mention when you make a pull request or comment on GitHub?

    ​When you make a pull request or need to communicate the next actions someone needs to take in a GitHub comment, you should use a @mention.

    Read more about @mention: https://help.github.com/articles/basic-writing-and-formatting-syntax/#mentioning-users-and-teams

    ​​github-mention-bad.png
    Figure: Bad example - Not using a @mention when addressing Duncan or Igor​
    github-mention-good.png
    Figure: Good example - Using a @mention
    Read more about Do you know to mention someone with a @mention when you make a pull request or comment on GitHub?

  6. Do you know to the requirements to create a new repository?

    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.​
    Read more about Do you know to the requirements to create a new repository?