5

I use GitHub PRs regularly. I wondered if I could "do PRs" independently of GitHub. That led me to read more about Git patches.

It appears that GitHub provides a convenient, web-based workflow around Git's patches. Is that accurate? Is the GitHub PR feature using Git patches under-the-covers? Or maybe the GitHub PR feature is simply doing a Git merge of the two branches? Maybe a Git merge is really using a Git patch in either case?

Could someone clarify the relationship, if there is one, between a Git patch and a GitHub PR?

Wallace Kelly
  • 15,565
  • 8
  • 50
  • 71
  • 1
    Could you clarify what you mean by "Git patches"? Do you mean using tools like [`git format-patch`](https://git-scm.com/docs/git-format-patch) and [`git apply`](https://git-scm.com/docs/git-apply)? – Schwern Jul 21 '20 at 17:45
  • 1
    I don't feel qualified to give a "real" answer about what GitHub is doing relative to how patches work, but your general sense is indeed correct. Most things that GitHub does (the code-changing things, as opposed to wikis or issue-tracking)... most things are actually wrapping the truly powerful features already present in Git. Many projects accept patch files via email. It looks like: http://lists.subsurface-divelog.org/pipermail/subsurface/2016-January/024017.html and you use `git am` to apply: https://git-scm.com/docs/git-am – pestophagous Jul 21 '20 at 17:46
  • @Schwern By "git patches" I mean whatever comes up when I search the web for "git patch" https://www.bing.com/search?q=git+patch – Wallace Kelly Jul 21 '20 at 17:48

1 Answers1

5

I'll assume by "Git patches" you're referring to git format-patch and git apply. Do Github PRs use these tools? No.

The Git patch tools exist for when, for whatever reason, you do not have access to someone's repository. Their most common use is email-based workflows using tools like git am to manage emailed patches. The people receiving your patches can use them to reconstruct your history. This is, effectively, an awkward replacement for the push, pull, and fetch commands.

Github PRs use the normal Git branch and merge commands (or rebase). You push the complete history of your branch to Github and it does the merge for you. You can perform them yourself. If you click on "view command line instructions" Github will give you the equivalent commands to run.

enter image description here

I'll explain each command.

Step 1: From your project repository, bring in the changes and test.

  • git fetch origin
  • git checkout -b issue/#1761 origin/issue/#1761
  • git merge master

Git does not talk to the network without your say so. git fetch origin efficiently downloads an updated snapshot of the remote repository called "origin". In this case that's the repository on Github.

Now that your idea of what's on Github is up to date, you checkout a local branch for the PR. In this case that's issue/#1761. origin/issue/#1761 is your "remote tracking branch", your local snapshot of the last place the branch issue/#1761 was the last time you fetched.

Then you merge master into your local version of issue/#1761 to bring it up to date. Now you can test it to make sure it works with the latest version of master. Oddly enough, Github does not do this last step of updating from master.

Step 2: Merge the changes and update on GitHub.

  • git checkout master
  • git merge --no-ff issue/#1761
  • git push origin master

Now that the branch is up to date, you checkout your local master branch, merge in your local version of issue/#1761 using --no-ff to ensure there is a merge commit even if it can be fast-forwarded, and then push your changes to master to Github.


You don't need Github for this. You can set up your own remote Git server using nothing more than ssh. It won't have all the bells and whistles, and no PR interface, but you can give people ssh logins to push and pull and do all the basic remote branching and merging.

Github uses the normal Git merge tools, though likely heavily modified to scale. The major thing Github brings is a simple way to set up a centralized remote repository for everyone to push and pull from, plus adding standardized authentication, review, and actions to the process.

And Github is not the only game in town for hosting extra process bells and whistles. There's Gitlab, Bitbucket, and other Git hosting services. As well as various stand-alone servers like Gitea and GitBucket.

Schwern
  • 153,029
  • 25
  • 195
  • 336