How to contribute code to git repositories that aren't hosted on GitHub
With just over 48 million public repositories (and growing fast [^repos]), GitHub is pretty much the de-facto place to host code, as pretty much everyone has an account there. By far the most useful feature GitHub provides is the ability to open pull requests (PRs).
Not all code repositories are hosted on GitHub, however - and these repositories do not get the same exposure and hence level of participation and collaboration that those on GitHub do, due in no small part (other reasons exist too though) I suspect because contributing to these repositories is unfortunately more complicated than opening a PR.
It needn't be this way though - so in this post I'll show you how to unlock the power of contributing code to quite literally any project that is under git version control. While knowledge of your command line is necessary, basic familiarity will suffice (see also my blog post on learning your terminal). I'll also assume that you have git installed, and that Windows users have already opened Git Bash and navigated to the cloned repository in question with
Step 0: Making your changes
This is the easy part. After cloning your repository in the normal way, make a new branch for your changes. GUI users should be able to navigate their interfaces. For those using the command line, do this from the source branch you want to branch from:
git switch -c new_branch_name
Then, make your changes in the usual way.
Step 1: Find contact details
Once you have your changes, you need to find somewhere to send them. This is different for every repository, but here are some common places to check for contact details:
- The project's README file
- The project's website (if it has one)
- Track down the author's name on other websites
- Email addresses of commits
Step 2: Make a patch file
Now that you've found a place to send your contribution to, we need to pack it into a nice neat box that can be transported (usually via email as an attachment). Doing so is fairly simple. You need to first identify the hashes of the commits you want to include. Do that with this command:
git log --one-line --graph --decorate
You might get some output that looks a bit like this:
* c443459 (HEAD -> some-patch) wireframe/corner_set: fix luacheck warnings * 3d12345 //smake: fix luacheck warnings * 4c7bb6a //sfactor: fix luacheck warnings; fix crash * 67b4495 (HEAD -> main, origin/main) README: add link to edit full reference * ee46507 fixup * 58933c6 README: Update command list * 6c49b9d fixup again * 364de73 fixup
In your terminal it will probably be coloured. The 7 digit hexadecimal value (e.g.
4c7bb6a) there is the commit hash. Copy the commit hash of the oldest and the newest commits in question, and then do this:
git format-patch --stdout OLDHASH..NEWHASH >somefilename.patch
NEWHASH with the oldest and newest commit hashes respectively. If the newest commit hash is the latest commit on the branch, then the keyword
HEAD can also be used instead.
Step 3: Submit patch file
Now that you have a patch file, you can send it to the author. By email, instant messaging, or avian carriers - any means of communication will do!
This is all there is to it. If you've received such a patch and are unsure about what to do though, keep reading.
But what happens if I receive a contribution?
If you've received a patch file generated by the above method and don't know what to do with it, read on! You may have received a patch file for a variety of reasons:
- Someone's interested in improving your project
- You've previously sent a contribution to someone else, and they've sent back a patch of their own along with a code review of things you need to change or improve
Either way, it's easy to apply it to your git repository. First, make sure you have the branch in question you want to apply the commits to checked out. Then, download the patch file, and do this:
git am path/to/somefile.patch
...this will apply the commits contained within to the currently checked out branch for you. If you're unsure about what they contain, don't forget that you can always open the patch file in your text editor and inspect it, or do this to see a quick summary:
grep Subject: path/to/somefile.patch
Once a patch file is applied, you can handle things in the usual way - for example you'll probably want to use
git push to push the commit(s) to your remote, or perhaps
git rebase -i to clean them up first.
In this post, I've shown you how to create and apply patch files. This is extremely useful when dealing with sending patches to code repositories that are either on servers where you can't create an account to open a pull request (e.g. Gitea) or just simply doesn't have a pull request system at all. It can even be used in extreme situations where a given code repository doesn't have a central remote server at all - this is surely where git get's its reputation as a distributed version control system.
Sources and further reading
- How to Create and Apply a Patch in Git
- What is the difference between git am and git apply?
- Sourcehut: https://sourcehut.org/
[repos]: Ref https://github.com/search?q=is:public as of 2022-01-06