iToto's Blog

A Montreal based full-stack web developer who loves learning and trying out new things. This blog is my attempt to document my work as well as a place to discuss ideas or topics that I find interesting. Feel free to follow me on linked social networks.

Fork or Die

For those who use git as their scm, you probably are familiar with the term forking. For those who aren't using git yet, do yourself a favour and learn it, you'll thank me later.

Fork, what?

If you are unfamiliar with the term, all it means is to make a "copy" the repository for your own development. This is very common in the open source community as contributors come and go frequently on projects.


Say you're browsing a project on GitHub. You realize that this project is missing a good encryption function. All you need to do is fork the project, develop your kick-ass encryption function and then submit a Pull Request to the project for the owners to review and merge.

Why should I fork?

When people first come to git from other scm/vcs alternatives, they instinctively think that forking is an un-needed process. This is common from those coming from a centralized scm such as svn or cvs.

There are tons of reasons why you should fork, to name a few:

  • Keep your main repository clean with only main branches containing stable code.
  • Avoid endless merge conflicts from contributors stepping on each other's feet.
  • Contributors feel less intimidated working on their own copies.
  • Setup hooks on main repository for deployment to environments.
  • Added security as you can set tight permissions on the main repository.

As git is a distributed scm, the notion of creating a copy of a repository fits well into it's design. The idea is simple: As a contributor, I work on my changes locally, then push them up to my own private remote. Once I'm done with my feature and feel it's ready to be added to the main project – that all other contributors have access to – I create a Pull Request from my fork to the main project.

What if I'm the only contributor?

As long as your project needs to be deployed to an environment (production/staging/etc.) then you should be forking. The idea is to keep your main repository clean and stable (for your deployments) and use your fork for development. With this, it doesn't matter if you're 1 or 100 contributors.

Sweet! When can I start forking?

There's no better time then now! Head over to GitHub and fork to your heart's content. Once your comfortable with it, be sure to start doing it at your work place. Your colleagues will probably bring you cake!

cake is a lie