Are there any advantages to forking private repo on GitHub?

Question

I'm one of a few developers working on a private GitHub repo in a small company. The repo was created by our boss under his GitHub account, and all the developers have push access to it.

As you may know, it's possible fork the main repo and the fork will sill remain private even if you don't have paid subscription. And everyone who's added to the original repo will be added to the fork's watchers list automatically (I have no idea why).

This is what I did a while ago out of curiosity (I didn't know I could do this) and because I thought it would be nice to keep my work-in-progress branches and temporary stuff outside of the main repo to keep things clean. But today my boss asked me why I did this, and I couldn't come up with a good reason except what I said above.

Are there any good reasons to fork a private repo on GitHub instead of pushing to the main repo directly?

Answer 1

One reason for needing to fork your boss' repository would be if he did not allow you to directly make contributions to this repository. However, since he is allowing you direct access, there is no explicit need to make a fork. As @Diego pointed out, GitHub likes to have users push and pull from their own repo, and then submit changes to the upstream repo via a pull request. However, forking is not necessary to review changes. An easy alternative would be to just create feature branches in your boss' remote repository and let him review those changes.

Answer 2

I think the best description of why you'd want private forks is Atlassian's explanation of the forking workflow. The following is how we do our repositories, forks and pull requests. It scales well past a handful of developers, and keeps things isolated until it's time to merge.

Setting up your local working copy:

1. Your company has a central paid GitHub account with one or more private repositories. These hold the "gold copy" of the repository. This repository is also tied into Continuous Integration (CI) tools like TeamCity as well as auto-deployment tools.

2. The central company repository has two branches. The "master" branch is what is in production and "development" is what is deployed to the QA server. You might even have a 3rd long-lived branch for a "staging" server.

3. Developers fork the repository to their own personal GitHub account.

4. A developer will clone from their personal fork, down to their hard drive with git clone git@github.com:username/reponame. This will make "origin" point at their personal fork.

5. Developers also add an "upstream" (naming convention) that points at the company repository. This is done with git remote add upstream git@github.com:company/reponame.

That's the end of the setup of a new working copy. Now we can do the day-to-day tasks.

1. For developers, prior to creating a new feature branch, they should update their local development branch with

   git fetch upstream && git checkout development && git merge
   --ff-only upstream/development && git push origin development
   ```.
   

2. Create a feature branch in the local working copy prior to starting to work on fixing an issue or adding a feature. This can be done with

   git checkout development && git checkout -b new-branch-name
   

   (If I'm working a GitHub issue, my branch names are 'i####-issue-description' where #### is the GitHub issue number.)

3. Start working on the feature branch locally, making commits. You can optionally immediately push them to "origin" (the personal fork on GitHub).

4. Once you are satisfied with your feature / fix branch and it is pushed up to "origin", you will create a GitHub Pull Request (PR) to merge it into the "development" branch of the company's repository. This give you a nice UI to review the changes, verify that they will merge cleanly into the company repository "developement" branch. If you are using CI, then you could also have GitHub run unit/integration tests on your code prior to allowing the merge.

5. Once your feature branch is merged into the company repository, it's no longer needed in your local working copy or in your personal fork. But I usually keep them around for 2-3 months after the change has been deployed to production.

6. We typically QA things on the "development" branch, then put together a PR to pull change from "development" into "master" for final deployment.

Sometimes you have merge conflicts, and you will need to rebase your feature branch.

1. Get the latest copy of "development" down into your working copy with

   git fetch upstream && git checkout development && git merge --ff-only upstream/development && git push origin development
   

2. Checkout your feature branch again with git checkout branch-name.

3. Perform a rebase with git rebase development.

4. Force-push the rebased branch to origin with git push --force origin branch-name.

5. The GitHub PR should now indicate that it has no conflicts with the "development" branch in the company repository.

Answer 3

Usually fork used in order to contribute to a repo where you don't have write permission.

In your case since you are all contributors there is no need for the fork.

If i want to contribute to repo in which im not a contributor and i wish to file a pull-request, i will do it from my fork.

Creating a “fork” is producing a personal copy of someone else’s project.

Forks act as a sort of bridge between the original repository and your personal copy.

You can submit Pull Requests to help make other people’s projects better by offering your changes up to the original project.

Forking is at the core of social coding at GitHub.

Answer 4

If you push to the main repository you loose the ability of having pull requests being reviewed, commented and eventually merged by whoever controls the repository.