GitHub 201: Collaboration and Branches

Now that you've learned the basics of hosting code on GitHub, let's get into collaboration, as more often than not, you'll be coding with other people, whether that is with a partner, group, an entire company, or just maintaining an open-source project!

Adding Users

Before we can collaborate, let's add collaborators to our repository. You can go to the repository's settings, and manage access. Authenticate, then add the GitHub usernames of people who you would like to collaborate with.

What is a Branch?

A "branch" on GitHub is a working copy of the code being hosted. Branches are used when you want to make changes and have them be tracked while they are still in development.

Most of the time, we will create a new branch based off of the current state of the main branch.

The Main Branch

The main, or master, branch, is the branch where all changes eventually end up. The code that the end user sees is deployed from the main branch, and this branch is never edited directly. Typically, code on the main branch has been reviewed and can be considered stable.

If we host this on GitHub pages, the user will always see main. With different branches, you can make changes that the user will only see once the bugs have been fixed.

---

When you create a branch based on main, the code is essentially copied, and you can work on the new copy independent from any changes that are pushed on main.

Some more terminology

• Deploy: copying code from a hosted source such as GitHub to a server so that users can view and interact with your website or application.
• Production: The code that end users see.
• Host: A place or service that owns the server you are using to serve your website.

---

Example

Suppose there's a website. Bob wants to add a button to navigation, and Sally wants to change the styling of the home page. They both want their changes to be reviewed before deploying the website to production.

1. Bob creates a new branch called "nav-button", and Sally creates a new branch called "update-styles". At this point, the main, nav-button, and update-styles branch are all the same.
2. As long as Bob and Sally don't change the same lines of the same files, Git can track and merge changes without second thought. Since Bob is working on the navigation bar, he will only be modifying HTML files. Likewise, Sally will only make changes to the "style.css" file.
3. After they make their changes, the code of the three branches are different. main is unchanged, nav-button has just Bob's changes, and update-styles has only Sally's changes

Pull Requests

Once developers have made their desired changes to their branch of code, they can create a "pull request" (also called a PR) to merge their code to main and push it to production.

To create a pull request, you can press ctrl/cmd + R in GitHub Desktop.

Alternatively, you can go to GitHub and create one under the "Pull Requests" tab, or

Give your PR a title and description detailing the changes, and choose someone or multiple people to review your code, whether that is your peer or QA (quality assurance).

Then, click "create pull request"

Approving or Requesting Changes

Once someone has looked at the code, they can go to the "files changed" tab. Then, click "start a review"

Add a comment, and select whether you want to approve the PR or request changes. Once you submit your review, the creator of the PR will be emailed.

If you requested changes and want to highlight specific lines of code that need to be addressed, find the file under "files changed" and drag the line numbers (on the left side of the file) until your desired selection is highlighted in yellow. Press the plus button, and submit your line-specific review before clicking "submit review"

Once the requested changes are addressed, the creator of the PR can request re-review of the PR, which will notify the person reviewing the code again.

Continuing our Example

4. At this point, both Bob and Sally can make a pull request (aka merge request).
5. Then, both of them will request review of someone who is reviewing their code, i.e. Alice.
6. Alice approves Bob's "nav-button" PR but requests changes on Sally's "update-styles" PR.

Merging PRs

To merge a pull request, Scroll down and find the "merge pull request" button. Click this, and confirm that you want to merge it.

Once done, you can delete the branch.

7. Bob can merge his PR since it was approved. Now, the main branch has Bob's navigation changes. Sally's branch has her changes only and NOT the changes that were just merged.
8. Sally addresses the changes to her "update-styles" branch and requests re-review from Alice, who approves her updated changes.
9. Since her code has been approved, Sally merges her changes. Main is now updated, and has both Bob's and Sally's changes.

Congrats, you've successfully made changes on a different branch, had someone review it, and merged it to main... you are now a true collaborative developer!