At the heart of GitHub is collaboration. The GitHub flow was developed for collaboration on projects. To make it work for teams regardless of their size or technical expertise, GitHub made sure each step in their workflow can be completed within the web-based interface.
There are two main types of collaborative development models:
- In the fork and pull model, anyone can fork an existing repository and push changes to their personal fork. You do not need permission to the source repository to push to a user-owned fork. This model is popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.
- In the shared repository model, collaborators are granted push access to a single shared repository and topic branches are created when changes need to be made. This model is more prevalent with small teams and organizations collaborating on private projects.
Below we'll cover:
You can invite users to become collaborators to your personal repository, which grants them read/write access to the project (shared repository model).
- Inviting collaborators to a personal repository
- Collaborator access on a repository owned by a user account
Issues and pull requests facilitate discussions on GitHub. Issues are useful for discussing specific details of a project such as bug reports and planned improvements. Pull requests allow you to comment directly on proposed changes.
GitHub has created a Community Profile checklist to help make sure your project meets the recommended community standards to help people use and contribute to your project. You can read more About community profiles for public repositories, Starting an Open Source Project and Building Welcoming Communities. You can also take the Community starter kit course in the GitHub Learning Lab to learn about the informal standards the community has adopted to make it easier to find and contribute to projects.
You can find the Community Profile checklist via the Insights tab and then select Community in the left sidebar. It checks to see if a project includes recommended community health files, such as
- Description
- README
- Code of Conduct
- Contributing guidelines
- License
- Issue templates
- Pull Request templates
I have listed definitions and resources below to help you get started on these files:
- Description: Add an optional short description about the repository which will be displayed in the right sidebar of the
Codetab. - README: A text file containing information about the files in a repository that is typically the first file a visitor to your repository will see. A README file, along with a repository license, contribution guidelines, and a code of conduct, helps you share expectations and manage contributions to your project.
- Code of Conduct: A document that defines standards for how to engage in a community.
- Contributing guidelines: A document explaining how people should contribute to your project.
- License: A document that you can include with your project to let people know what they can and can't do with your source code.
- Issue and Pull Request templates: With issue and pull request templates, you can customize and standardize the information you'd like contributors to include when they open issues and pull requests in your repository.
Project boards on GitHub help you organize and prioritize your work. They are made up of issues, pull requests, and notes that are categorized as cards in columns of your choosing. You can create project boards for specific feature work, comprehensive roadmaps, or even release checklists. With project boards, you have the flexibility to create customized workflows that suit your needs.
Every GitHub repository comes equipped with a section for hosting documentation, called a wiki. You can use your repository's wiki to share long-form content about your project, such as how to use it, how you designed it, or its core principles. A README file quickly tells what your project can do, while you can use a wiki to provide additional documentation.
Previous: Using GitHub Demonstration
Next: More Resources