Collaborating on GitHub
GitHub hosts millions of public repositories. You’re encouraged to copy and improve or modify them as much as their license allows. The mechanism for this that Git and other services use is called fork. It’s not part of the standard Git program on your computer.
Forking a repository makes a copy of that repository in your account on GitHub. From that point forward, you can treat it like every repository you create. You can clone, branch, make changes, and merge. Nothing you do affects the original repository. If you ever want your changes merged with the official repository, you make a pull request. Then, the owners of the repository can accept your changes or not.
Making a Fork
Once you’ve found a repository On the GitHub website you’d like to fork, click the “Fork” button. A form similar to the “Create new repository” form lets you change your copy’s name and description. After clicking “Create Fork”, the repository appears like all the others you’ve created.
Important: This fork you’ve created will remain public. Unlike your own repositories, you can’t switch the visibility to private. If you want the contents to be in a private repository, you must make an empty, private repository and manually copy the files from the working directory.
At the top of the file list in GitHub is a status bar telling you how many commits separate your copy from the original. You can pull changes from the original into your copy anytime using the “Sync fork” button.
If you clone this repository to your local computer and ask it about its remotes using the git remote command, it doesn’t indicate that it’s a forked repository. You only see that information on the GitHub website.
Collaborators
Because forking works only with public repositories, you can’t use it when you want to collaborate with your team on a private project. Also, by default, only the owner can merge changes on public repositories. Everyone else has read-only access.
To let others have write access to a repository, you must add each one as a collaborator. On the GitHub website, you can do that from the repository’s “Settings” tab, which isn’t the same as your profile settings. Then, you can invite a collaborator. If you know the person is on GitHub, you invite them by their username. Otherwise, you invite them by email.
After sending the invitation to the collaborator, they have seven days to accept it. Once they accept, they have write access to the repository. They can clone, make branches, and push their changes to the remote.
On a larger project, you might want to avoid even trusted collaborators pushing to any branch they want. In that case, you can set up rulesets in the repository settings to protect certain branches. However, free-tier accounts can’t use rulesets.
Pull Requests
To let people make forks of a repository and propose changes, GitHub invented a system called pull requests, which most services have since adopted. The idea of a pull request is that before a branch or fork gets merged into the main branch, it undergoes a review process and only gets merged after the collaborators agree it’s a good change.
Each time you publish a branch to your GitHub repository, you see a button to create a pull request the next time you visit the GitHub website.
Clicking that button gets you a form to title and describe your pull request. You can also say which branch you’d like to merge this branch into. The default is always whatever branch this branch originally diverged from.
Once you’ve made a title and description, you can add reviewers. Only collaborators can be reviewers. You can also assign collaborators to the pull request.
GitHub emails every reviewer or assignee, telling them about the pull request. Then, they can go to the GitHub website and see proposed changes. They can comment on all the changes or specific lines. Each of those comments starts a discussion thread that each collaborator can see and participate in.
After reviewing the code and potentially making comments, a collaborator can approve the pull request, request changes, or comment.
The pull request’s author can make more commits on the branch and push them to the remote. The pull request updates with those commits.
Once everyone is satisfied, the changes can be merged. To keep things working, GitHub doesn’t allow a pull request to merge if it will cause a conflict. It’s the author’s responsibility to merge and resolve conflicts on their local copy and then push those changes to the pull request.
After the pull request gets merged, it can be closed. At any time before it’s merged, it can also be rejected. The pull request and the discussion around the changes are saved as part of the repository on GitHub.