Git fork

Fork gives us awesome power to suggest improvements to open-source projects, but it also can be used in enterprise scenarios.
In this example I’ll review the most common scenario when a user will make some improvements for open-source project.

We can fork repo directly from BitBucket GUI:

Screen Shot 2016-06-23 at 16.59.40

After repo is successfully forked, typically we can see an origin (our fork) but not an upstream (original repo):

Screen Shot 2016-06-23 at 17.04.08

So let’s add an upstream and check results:

Screen Shot 2016-06-23 at 17.08.29

Now, when code in upstream is changed we’ll be able to pull changes (that’s the main aim of upstream adding):

Screenshot at Jun 23 17-14-42

Let’s create our new-feature branch and add our new code to it:

Screenshot at Jun 23 17-26-36

Now we can share our work with project owner by creating pull request:

Screen Shot 2016-06-23 at 17.28.42

Owner of the original repo can review your code and merge to some branch:

Screen Shot 2016-06-23 at 17.31.09

And if your feature is useful it can become a part of the product by merging to the master branch:

Screen Shot 2016-06-23 at 17.33.36

For GitHub procedure it is almost the same, but you’re not able to create new branch so simple as in BitBucket:

Screen Shot 2016-06-23 at 17.49.05

Screen Shot 2016-06-23 at 17.49.49

VCS table of contents