The Gluster Blog

Gluster blog stories provide high-level spotlights on our users all over the world

Idiomatic Github development : pull request + fetch remote


When getting started with github, its easy to get confused between “forks” and “branches”.  In this post we’ll go through a simple workflow for pull-request driven development, including the necessary “trick” to keep your personal “forked” repository in sync with the original github repo.

1) Forks are personal – you can “fork” a git hub repository as a way to start developing against an existing repoistory without being coupled to it.  
2) Branches are not necessarily personal : their namespace shared in the same original repository.
Using branches as a commiter on the primary repo:
1) Become a commiter on the repo, write your own branches, and then merge your branches into head.


Contribute by using pull-requests as a non-commiter:
2) FORK the original repo, write code anywhere (including on your “master” branch), and simply issue pull requests upstream. 
The advantage of the 2nd approach : 
1) It doesn’t require you to be a registered commiter on a project.
2) It doesn’t constrain your workflow (you can write and push changes directly to your master, without worrying about branches).   
3) It naturally enables the convenient github enabled pull user interface as a methodology for incorporating fixes.
In any case, the above methodologies will allow you to develop without effecting the “real” master, and you can use a pull request to “simulate” the insulation provided by branching.
However at some point you will want to pull the changes from the main repo into your fork.  You can do this by adding a 2nd remote to your fork, as follows (see 6 below):
An example:
1) Fork
2) git clone
3) git remote add upstream
4) Edit some stuff.
4) git add -A . ; git commit -m “my first commit to my fork” ; git push
5) Issue a pull request
#A few days later, maybe the original repo changes, and we want to pull those changes down:
6) git fetch upstream <– keep your fork in sync with the original repo.


  • 06 Dec 2020
    Looking back at 2020 – with g...

    2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...

    Read more
  • 27 Apr 2020
    Update from the team

    It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...

    Read more
  • 03 Feb 2020
    Building a longer term focus for Gl...

    The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...

    Read more