1.6 KiB
title | description | date | tags | |
---|---|---|---|---|
Working With Forked Repos | Fetching upstream and things | 2020-02-02 |
|
Though I've been building web apps for many years, my direct experience with contributing to open source projects is surprisingly limited. Thus when I found myself forking and maintaining a fork as I submitted several PR's for a single project over time I was a little lost with what to do.
So here are some things I've learned thus far.
Why Fork, and How do I Fork?
Github, Gitlab and other source-code repositories allow for you to "fork" code. I previously thought this was to split work into a different direction, but in fact its also to give a developer control over proposed changes they'd like to push back to source. Thus, submitting a PR to an open source repository looks like this:
- Click
Fork
on the source-code repository - Clone your newly forked repository
- Make your changes on a new branch
- Push your branch to your forked repository (A misconception I had was you may not push a branch to many open source repositories directly, this is intentional)
- Create a PR that merges your branch from your fork to the original non-forked repository
Updating the Forked Master Branch
Over time your forked repository will get out of date. A common scenario is desiring to get the latest master from the source repository.
git remote add upstream ORIGINAL_PROJECT_CLONE_URL
git fetch upstream
git checkout master
git rebase upstream/master
Now you may do all the standard things you wish, such as merging master into your current branch git merge master
to stay up to date with your proposed changes.