Discover Collaboration within GitHub
After completing this unit, you’ll be able to:
- Build organizational structures that facilitate collaboration.
- List the most commonly visited sections of a GitHub repository.
- Explain the collaboration features that exist alongside your source code in GitHub.
Before we dive in and try out Git commands in unit 4, let's first talk about the structure of GitHub and how it can help you collaborate with your team.
A repository is the most basic element of GitHub. It’s easiest to imagine it as a project folder. However, unlike an ordinary folder on your laptop, a GitHub repository also offers simple and powerful tools for collaborating with others.
A repository contains all of the files associated with a project (including documentation), and stores each file’s revision history. Whether you’re just curious or you’re a major contributor, knowing your way around a repository is essential!
Planning and code live side by side, but are also completely intertwined within a GitHub repository. This ranges from being able to search a repository for specific code to the ability to see previous versions of files to identify what commits affected those versions and what conversations were associated.
Effective planning starts by understanding who’s who. Setting up teams and organizations on GitHub can make the process of collaboration much smoother.
When you sign up for GitHub, you’re automatically given a user account. Permissions for a user account are pretty simple—you add people as collaborators to specific repositories.
Organization accounts provide more granular control over repository permissions. For them, you create teams of people and then give those teams access to specific repositories. Permissions can be assigned at the team level (for example, read, write, or admin), though you can also do this on a user-by-user basis.
Teams are a powerful feature of GitHub, and can be structured based on actual team structure in the company, or ad-hoc based on skills, interests, and expertise that may be outside of the user’s designated role.
There’s a lot of information in a repository on GitHub. Initially, the most important sections to focus on are Code, Issues, Pull Requests, and Projects.
The code view is where you’ll find the files included in the repository. These files may contain the project code, documentation, and other important files. We also call this view the root of the project. Any changes to these files will be tracked via Git version control.
When you visit a repository, the code view automatically shows the default branch. When you create a repository, the default branch is called master, but you can change it if you prefer something different. You can also show any branch that has been pushed to the remote by simply selecting the branch in the dropdown.
Much like a forum, issues are a threaded discussion incorporated right into a GitHub repository. You can use them to track bugs and feature requests, and you can assign them to specific team members. They’re designed to encourage discussion, collaboration, and even community involvement.
Issues are simple and lightweight, and are meant to be used in conjunction with the other powerful features of GitHub. When used together, issues create links to other issues, pull requests, labels, milestones, and projects.
A pull request is a comparison between two branches. Generally, that comparison is between master (the branch with production code) and another branch used for code in development. The pull request represents a change to the code. This can mean adding, modifying, or deleting files made on a branch, which the author would like to incorporate in another branch (again, typically in the production code). Frequently, the work being done within a pull request originates from an issue in the repository.
A pull request is also a place where you can have extended conversations about the changes between two branches. Let’s say that Ali introduces a bug fix, but accidentally creates a new bug when resolving the fix. Sally can view this work, send a quick comment (on the pull request) to Ali identifying the new issue, and either fix the problem herself or give Ali a chance to make quick edits before merging.
Pull requests help you write better software by facilitating code review and showing the status of any automated tests. This is not to be overlooked—a pull request compares code, gives a platform for conversation about that code, encourages collaboration thorough code review, and works seamlessly with a variety of integrations (including testing!). The pull request is one of the most powerful aspects of collaboration on GitHub.
Issues and pull requests are fantastic and offer huge benefits for various collaboration styles. Projects bring them together to make tracking and planning larger-scale work more intuitive.
Projects let you visualize your work with Kanban style boards—moving task cards, issues, and pull requests along custom columns. Projects can also be created at the repository or organization level, and thus can incorporate issues or pull requests from multiple repositories into a single planning page.