Add code via Pull Request under GitHub


Contribute to Free / Libre Open Source Software, Part 2 Code via Pull Request at GitHub

Git is standard for version management, GitHub is almost standard for Git platforms. And pull requests, in turn, are the standard way to contribute code to GitHub – an important foundation that every developer should know.

Company about the topic

If a pull request contains many different commits, it can be helpful to merge the changes into a single commit using squashIf a pull request contains many different commits, it can be helpful to merge the changes into a single commit using squash

(Image: Lang / GitHub)

GitHub is used in a commercial-proprietary environment, but above all the Microsoft platform is known for open source projects. Now there are many opportunities to contribute to different FLOSS projects, but the most important contributions are still new code and code corrections.

These are usually about Pull Requests built-in-but there is more than one reference to the command “git pull”. At GitLab, the equivalent function is called Merge Requestsays the same thing, and also points to more than the “git merge”command.

Pull requests are about providing code, initiating a review process, and finally actually merging the patches with the repo. One of the big advantages: any GitHub user can propose changes to any project without having to connect or contact the operators in any other way – it’s a standardized process with very little overhead.

In the following, we present the complete process in detail, both from the point of view of the contributor and the administrator of the repo. The basic outsourcing workflow looks like this: Clone repo, create feature branch, edit, commit, push, pull request, review process, merge-and just step by step.

Submit Pull Request

Step 1 finds on instead of: Fork the repo you want to contribute to. In the following, for the sake of clarity, everything takes place on a real repo with real URLs.

Now, switch to the command line and clone the Repository:

git clone

Now you should set up the local fork repo so that you can update your master from the original master and merge with it – this is not necessary:

git remote add upstream
git fetch upstream
git checkout master
git merge upstream/master

The actual work can then be started – and this begins with a separate branch for the planned feature, correction or other change, i.e.:

git branch mybranch
git checkout mybranch

This is followed by the changes in the repo, without any special features. However, only one topic may be implemented per branch. The whole procedure ends as usual with a normal “git commit”. Since this commit is intended for third parties, you should pay special attention to a good, understandable commit message.

Now it becomes optional again: before the commits are pushed, it serves to get an update from the original master again and to include any new commits in the meantime into the working branch via rebase command-simply to make life easier for the project manager:

git fetch upstream
git checkout master
git merge upstream/master
git checkout mybranch
git rebase master

A final step locally in the terminal-as expected:

git push — set-upstream origin mybranch

Thus, the changes are now in the forked repo on Github, where it continues: Via the button “Compare and Pull Request” you get to the form for pull requests. First of all, here you will find the comparison between the original master branch and its development branch, here “mybranch”. If everything fits, you can send the pull request.

Alternatively, the pull requests can also be sent as pure drafts, for example if the feature to be developed is still in an early stage and it should be clarified by pull request whether its completion is worthwhile at all. However, the draft status is not essential, since the administrator of the original repo can also set this status later. Pull requests in draft status cannot be merged, it is only a small hedge.

Test and install Pull Request

Now the perspective is changed: in the original repository the submitted pull request now appears, which confronts the administrator with four options: accept and merge pull request, move it to draft status, reject it or simply comment on it.

In advance, however, the administrator will usually want to test! First, the file must be .git/config can be customized with the following entry below [remote “origin”]:

fetch = +refs/pull/*/head:refs/pull/origin/*

All pull request branches can now be queried:

git fetch origin

As a result, there is a numbered list, for example:

* [new ref]     refs/pull/8/head -> refs/pull/origin/8

Here the pull request ends up in Branch “8”, which of course can also be checked out:

git checkout -b 8 pull/origin/8

The changes to the pull request are now available in the working directory and can be tested – but in read-only mode.

By default, a comment will follow after testing, provided that it is not just minor corrections – so a review process begins. With GitHub, this is kept pleasantly simple: the discussion can take place directly on the pull request page in the browser.

Further commits that come from the pull request creator from its “mybranch”branch automatically end up in this pull request. So you can make any adjustments without having to create a new pull request. After all details have been discussed, implemented in the code and committed, the original administrator can install the pull request final.

This is most easily done via – of course also here, with options: As usual, you can work here with the Merge, Rebase or Squash & Merge. Which option is available depends on your own internal project regulations, but also on the procedure of the pull request creator-if the pull request creator packs 50 individual commits into the pull request, a previous squash merge into a single commit might be quite helpful.

The final Pull Request Merge on final Pull Request Merge on

(Image: Lang / GitHub)

Once selected and commented if necessary, a click on the “Confirm Squash & Merge”button completes the process on the server side. As an alternative to the browser, you can also gemerged in the terminal-in the very regular way by pulling the “mybranch”branch from the forked repository:

git checkout master
git pull mybranch
git merge mybranch
git push origin master

Finally, there is a …

git branch -d mybranch

… to delete the already merged development branch.

Merge Request

If you are somewhat familiar with Git, it should have become clear: basically, pull requests are simply merges of third-party development branches. With GitHub it is called Pull Request after the first action in the original repo, the “getting” of the branch, with GitLab it is called Merge Request after the last action in the original repo, the merging of the branch.

Basically, the pull request workflow is quite simple, even if dealing with it is not really intuitive and at least in the terminal here and there a bit frizzy, if you look at the pulling of pull request branches, for example. But of course, this git workflow also becomes more complex when many sides are working on it, conflicts occur or simply accidents happen during mergers or rebases.

So let’s end with the – hopefully – very obvious tip: before you become productive with it, you should create a second Github account and test, test, test.


Ready to see us in action:

More To Explore
Enable registration in settings - general
Have any project in mind?

Contact us: