This site collects work by Aram Zucker-Scharff from all over the web.
Sometimes you’re working with an open-source code library that has a number of interested contributors but has been abandoned by the project maintainer. There are a few options for keeping the project up to date. The most obvious one is to cut the branch off the tree and start your own repository. However, that’s not always the optimal solution. Sometimes the maintainer is fairly high profile, or the code is linked in a lot of places, or for whatever reason abandoning the base git tree just won’t work.
In that case, there are options for essentially running the project from upstream; where you keep your branch attached to the original project tree, but pull in the pull requests from other interested parties. Using this technique you can keep your branch up to date with the best pull requests, but without fracturing the project. In addition, if the project maintainer ever comes back, they’ll have a handy single pull request with all the new features that you’ve been maintaining.
This is based on a StackOverflow response.
First you’ll want to add the other upstream fork as a remote of your repository.
otherfork in this example is the name you are giving the remote repository (like origin). You can add as many other forks as you’d like, as long as you give them different names.
If you find that the other upstream repository is storing their commits for the pull request on something other than their
master branch, then you’ll need to bring those other branches in too.
git fetch otherfork patch-branch
Once that is done, you can treat
otherfork/patch-branch like any other branch in your repository. If you want to bring in the commits from the pull-request on the downstream project, you have a few options.
cherry-pick the SHA of the commits you want to integrate:
git cherry-pick <first-SHA1> <second-SHA1> <etc.>
You can use a standard merge, or a
git merge otherfork/patch-branch
git pull otherfork patch-branch
Using these methods you can have your version of the codebase living upstream of the project base but still examine, test and merge pull requests to the base as if you were the project maintainer. This should make it easier to have up-to-date code without fragmenting the project.
This is weird, but I’ve sort of become addicted to walking the Pulaski bridge. I mean just look at that view. (at Pulaski Bridge)
A video posted by Aram Zucker-Scharff (@aramzs) on Jan 31, 2016 at 6:46am PST
Ain’t no rest for the wicked. (at Pulaski Bridge)
“Well, I say we get drunk, because I’m all out of ideas.”