What is a GitHub pull request and how do I apply it?

Answer 1, authority 100%

Let’s watch our hands.

1. A cool programmer created a repository.
2. You have forked its repository (i.e. copied it to yourself).
3. You’ve made some cool changes to your repository.

Now if you want the cool uncle to make your cool changes to his cool code. And you ask him to take your changes, i.e. did git pull . This is called pull request

Answer 2, authority 46%

The following can be added to the above. Not all pull requests are accepted by developers. There are a number of rules to follow:

1. The Pull Request (PR) must be well designed and contain
   comprehensive description.

2. The usual rule is one bug – one PR, one feature – one PR. Not necessary
   trying to cram a bunch of things at once.

3. It is very important to follow the Code Style of the project for which you
   do OL. Even if it seems unnatural to you (for example
   you always indent with 4 spaces, and in the project there are tabs).

No need to be afraid to do PR-s, because you can help even with little things. For example, you noticed a translation error in the readme file, or you think that some description of a feature can be rephrased more clearly.

There are millions of projects on github that live solely on the enthusiasm of the creators, good PRs very well spur this enthusiasm)

Answer 3, authority 22%

A Pull Request is something like a message to the author of the original repository with the meaning “hey, I did a cool thing here, I recommend adding it to such and such a branch.” The author of the original turnip looks at your “cool stuff” and decides whether to pull or not, merge into the branch or not.

more additions to the above: a possible (I use it) mechanism for working with turnips / pr:

fork a repository, for example https://github.com/rbock/sqlpp11

then

git clone https://github.com/your_username/sqlpp11.git

cd sqlpp11

git remote add upstream https://github.com/rbock/sqlpp11.git (i.e. we add an upstream alias for the original repository, we cannot add changes to it, but we can get them)

git checkout -b BranchName (branches)

now you edit files in your origin, in your branch, push them to your github fork (origin), from where you make a pull-request

with this you can do git merge / pull / fetch upstream from the original repository (upstream)

if the upstream has an integration of the travis-ci type (as in my example), it is better not to make pull requests until you configure travis-ci for your repository and your builds will not work correctly (so as not to torment the upstream maintainer with meaningless messages about failed builds in the pull request)

the general algorithm of work is something like this:
git fetch; git merge upstream / branch; (master / debug / etc.)
made changes: git push , the changes are sent to your fork on gitahab. If travis is configured, tests / builds pass, when you are sure of the quality of the commit, make a pull request from your fork. If the PR is accepted, let’s say git checkout master; git fetch; git merge upstream / branch to keep your fork consistent with the original.

branches embedded in upstream (original repository) and in your origin / master (your fork on github, in this case) can be deleted – manually or using, for example, https://github.com/arc90/git-sweep

Answer 4, authority 18%

1. What is a pull request?

1. Definition

pull request – a proposal to change the code in someone else’s repository.

You fork someone else’s repository (which sometimes itself can be a fork) → make changes in your fork → by pull request, offer changes to the owners of the repository whose fork you forked. On GitHub, a pull request to the public repository can be done by any registered contributor / contributor .

2. Components of pull requests

1. Changes you are about to make to someone else’s repository
2. Description of these changes.

Recommendations for competently submitting pull requests are outlined in in response from uv-th IonDen .

3. Varieties of pull requests

All pull requests can be categorized as follows:

1. Fix bugs, errors, conflicts with other applications,
2. Adding new functions, capabilities,
3. Refactoring, style changes. If the repository owner / owner is not much less versed in the repository code than you are, better not to abuse pull requests in this category.

4. Additional link

• “Pull requests on GitHub or How can I make changes to someone else’s project” – article on Habrahabr .

2. How to make and accept a pull request using hub

1. What is hub?

hub is a console application that simplifies the introduction of git commands, a wrapper for git. For example, to clone a repository using git, we would type in the terminal:

git clone https://github.com/Kristinita/SashaSublime.git

In hub, the command looks simpler:

hub clone Kristinita / SashaSublime

For a complete list of hub commands, and what they simplify, see the hub documentation .

At the time of this writing (Nov 2016) hub is running only with GitHub, not BitBucket or other resources for storing code. For Windows users installation available via Chocolatey package manager – cinst hub - y .

2. Why use hub?

Fix minor bugs and typos and then make pull request easier with GitHub web interface . However, if your changes are quite significant, it is better to clone the repository to your computer for the following reasons:

• IDEs / advanced text editors provide significantly more options for working with code compared to editing on the web;
• You may need various kinds of tests that are not available when editing in the web interface;
• For many, it is preferable to work in a terminal.

So you’ve decided to clone the repository. hub makes it easy:

• Cloning a remote repository; discussed in clause 2.1 of this answer;
• Fork; just type hub fork ;

into the terminal

• pull request; after you have pushed the changes to your fork, just enter hub pull-request into the terminal.

3. Configuring hub before use

1. Create custom environment variable GIT_EDITOR , it can be done simply with Rapid Environment Editor , – the value for which will be the path to the executable file of your editor, in which it is convenient for you to write a pull request message, – a description of your pull request, – if necessary adding command line arguments . For example, for my Sublime Text, the value came out as follows:

"D: \ Sublime Text 3 x64 \ sublime_text.exe" -n -w

If the path to the executable file contains spaces, to avoid bugs , you’d better enclose it in quotes.

2. When using hub on Windows and opening editable files in Sublime Text, there may be problems with pull requests as administrator. Since this is not my first problem with UAC, and I don’t see any sense from it, I disabled user account control.
3. Comments – the text under the message in the PULLREQ_EDITMSG tab – by default are highlighted with # octotorpes # . But when you submit a pull request to someone else’s repository, you will find that the text below the message appears as headers, not comments.

Requires git configuration. Enter the command in the terminal:

git config --global core.commentChar%

From now on, comments in the PULLREQ_EDITMSG tab will be preceded by % percent% symbols, after making a pull request, comments will not be visible both visually and in the source code of the pull request description.

If you need to back up or sync your custom git config, find out where git config files are stored, since 2.8 with the command:

git config --list --show-origin

For example, in Windows 10, the path to the file where this setting for comments is stored turned out to be the following:

file: C: /Users/SashaChernykh/.gitconfig core.commentchar =%

If your problem is different from those described here, and its resolution cannot be found by searching Google and by repository; try again to reproduce the problem by sending the following command to the terminal before entering the hub commands:

set HUB_VERBOSE = 1

Debug information will appear in the terminal. If you still can’t resolve the issue, please submit a bug report to issue tracker hub, attaching your terminal output along with debug information to the message.

4. An example of creating a pull request via hub

Let’s use PowerShell and hub pull request to the repository https://github.com/LightAlf/bioRepo1 . In addition to the above hub commands, the example also uses git commands, the purpose of which can be found, for example, from this or this resources in Russian.

PS E: \ & gt; hub clone LightAlf / bioRepo1
Cloning into 'bioRepo1' ...
remote: Counting objects: 16, done.
remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
Unpacking objects: 100% (16/16), done.
PS E: \ & gt; cd bioRepo1
PS E: \ bioRepo1 & gt; Invoke-Item README.MD
# The README.MD file opens in your editor → make changes → save the file.
PS E: \ bioRepo1 & gt; git add.
PS E: \ bioRepo1 & gt; git commit -m "Test pull-request via hub"
[master 839c146] Testing pull-request via hub
 1 file changed, 2 insertions (+)
PS E: \ bioRepo1 & gt; hub fork
Updating Kristinita
From https://github.com/LightAlf/bioRepo1
 * [new branch] discuss - & gt; Kristinita / discuss
 * [new branch] master - & gt; Kristinita / master
new remote: Kristinita
PS E: \ bioRepo1 & gt; git checkout -b SashaGoddess
Switched to a new branch 'SashaGoddess'
PS E: \ bioRepo1 & gt; git push Kristinita SashaGoddess
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 471 bytes | 0 bytes / s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/Kristinita/bioRepo1.git
 * [new branch] SashaGoddess - & gt; SashaGoddess
PS E: \ bioRepo1 & gt; hub pull-request
# A tab with the PULLREQ_EDITMSG file will open, as in the picture below → enter changes into it → save the file → close it.
https://github.com/LightAlf/bioRepo1/pull/2
PS E: \ bioRepo1 & gt;

Result :

5. Example of accepting a pull request using hub

If a pull request is offered to you, you can accept it from the terminal using the hub command – hub merge . The changes will be pushed into your local repository; to transfer them to remote, you should do git push . An example of how to accept a pull-request. if the branch suggested to make a pull request is default branch .

SashaChernykh @ DESKTOP-0G54NVG MINGW32 / e / SashaChocolatey (master)
# Where E: \ SashaChocolatey is the local repository where the pull-request was made to the associated remote repository
$ hub merge https://github.com/Kristinita/SashaChocolatey/pull/1
# Where https://github.com/Kristinita/SashaChocolatey/pull/1 - link to pull-request
Merge made by the 'recursive' strategy.
packages / Karens Replicator / tools / chocolateyinstall.ps1 | 13 +++++ --------
 1 file changed, 5 insertions (+), 8 deletions (-)
SashaChernykh @ DESKTOP-0G54NVG MINGW32 / e / SashaChocolatey (master)
$ hub push
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (15/15), 1.56 KiB | 0 bytes / s, done.
Total 15 (delta 8), reused 0 (delta 0)
remote: Resolving deltas: 100% (8/8), completed with 3 local objects.
To https://github.com/Kristinita/SashaChocolatey.git
  79ebe12..5045130 master - & gt; master

Result :

In the commit description, by default, there will be links to the commit that accepted the pull request, and to the pull request itself, as well as its title.

The GitHub user / user from whom you accepted the pull request will not immediately, but will be listed / listed as a contributor to your repository.

3. Additional link

• Hub documentation and command list .