Should you fork or branch on Github? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 yea开发者_Go百科rs ago.

Improve this question

Many github repos demand creating a fork on every essential code change.

Which is exactly like branching in git.

Why did github introduce forks?

---

(I like the idea of a git brunch - git users meeting up on a Sunday for lots of fried food ;))

The idea of forking a project on github and making changes in your own repository is that the owners of the project don't need to trust you or give you push access to their repository. If you want them to consider merging code from your repository then you can send them a pull request. GitHub has a nice system of pull requests where the upstream developers can review and comment on your contribution.

In a group of trusted developers, where everyone can push to one shared repository, you typically do push each new feature you develop as a new topic branch, and ask other people to review your work and consider it for merging.

One of the many nice things about git is that it doesn't particularly matter which repository a particular branch tip is in - that commit will always have the same SHA1sum, so you can push and pull it around as you like. It doesn't matter really if it's in a fork on GitHub or pushed to a shared repository or whatever...

---

To expound a bit on your question of "why can't I just push my branch to their repo?", consider that even if github made it possible for you to do this without potentially breaking the entire repo for everybody, most maintainers still would not be happy having their clean repo turn into a dumping ground for dozens or hundreds of branches.

Other contributors seeing these branches would assume that the upstream developer was working on them, even if they were really long-abandoned half-finished contributions from third parties.

The funny thing is, the workflow for you is exactly the same either way, with the addition of you clicking a "fork" button at some point on the upstream repo.

Compare:

1. git clone git://github.com/somebody/someproject
2. git checkout -b mycoolfeature
3. hack hack hack
4. git push origin mycoolfeature
5. submit pull request for mycoolfeature branch

vs

1. Click "fork" at github.com/somebody/someproject
2. git clone git://github.com/you/someproject
3. git checkout -b mycoolfeature
4. hack hack hack
5. git push origin mycoolfeature
6. submit pull request for mycoolfeature branch

There really is absolutely no overhead for you in creating a fork.

If you already have a clone of the upstream repo, and you're worried that you'll have to make a new clone and waste some time, try this workflow:

1. Click fork
2. cd someproject (your existing clone)
3. git remote add myfork git://github.com/you/someproject
4. git checkout -b mycoolfeature
5. hack hack hack
6. git push myfork mycoolfeature
7. submit pull request for mycoolfeature branch

Hope this helps!

---

A github fork means that you have a github repo, so you can push changes onto this. That means the changes you make are visible and on github, but the original owner does not need to include them.

Creating a fork provides you with a writable version of the repository.

Branches are totally different to forks in this regard. A fork can have many branches.