A forking rebase wokflow with GitHub is a common Git workflow, whether you're trying to work on open source or collaborating on work projects or your own.
Knowing how to properly fork and generate pull requests is essential.
It is easy to make mistakes when you're learning the process. In an attempt to gather this information for myself and others, this short tutorial for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
On the GitHub page and click the "Fork" button. Once you've done that, you can use your favorite git client to clone your repo or just head straight to the command line (my method of choice):
# Clone your fork to your local machine using ssh credentials
git clone git@github.com:USERNAME/FORKED-PROJECT.gitIf you plan on doing anything more than just a quick fix, you'll want to make sure you keep your fork up to date by tracking the original repo that you forked. To do this, you'll need to check on your remote repo:
# Verify the new remote named 'origin'
git remote -vWhenever you want to update your fork with the latest changes, you'll need to first fetch the upstream repo's branches and latest commits to bring them into your repository:
# Fetch from upstream remote
git fetch upstream
# If you are also using a rebase workflow (instead of merging) you can pull --rebase to get
# the newest changes on a remote branch
git pull --rebase origin
# View all branches
git branch -vaIf there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - see the next section, you may have to deal with conflicts. When doing so, be careful to respect the changes made remote.
Now, your local main branch is up-to-date with everything modified remote.
Whenever you begin work on a new ticket, bugfix, or any old poking around, it's important to create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the main branch so that you can easily submit and manage multiple pull requests for every task you complete.
To create a new branch and start working on it:
# Checkout the main branch - typically this is the main development branch with the most updated code
git checkout main
# Switch and create to your new `newfeature` branch
git checkout -b newfeatureNow, you are ready for whatever changes you want to create.
Prior to submitting your pull request (PR), you can clean up your branch and make it as atomic as possible for the original repo's maintainer to test, accept, and accept your work.
If any commits have been made to the remote main branch, you should rebase your development branch so that it is up to date with the remote repo.
# Fetch upstream master and merge with your repo's master branch
git pull --rebase mainNow, it might be desirable to squash some of your smaller commits down into a small number of larger more atomic, manageable commits. You can do this with an interactive rebase:
# Rebase all commits on your development branch, this ex is for 3 commits that you have locally
# Change up that HEAD~3 to whatever your commit number is.
git rebase -i HEAD~3This will open up a text editor where you can specify which commits to change.
Once you've committed and pushed all of your changes to GitHub, your fork or the remote repo and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.
Take note that unlike the previous sections which were written from the perspective of someone that created a fork and generated a pull request, this section is written from the perspective of the original repository owner who is handling an incoming pull request. Thus, where the "forker" was referring to the original repository as upstream, we're now looking at it as the owner of that original repository and the standard origin remote.
Open up the .git/config file and add a new line under [remote "origin"]:
fetch = +refs/pull/*/head:refs/pull/origin/*
Now you can fetch and checkout any pull request so that you can test them:
# Fetch all pull request branches
git fetch origin
# Checkout out a given pull request branch based on its number
git checkout -b 999 pull/origin/999Keep in mind that these branches will be read only and you won't be able to push any changes.
In cases where the merge would be a simple fast-forward, you can automatically do the merge by just clicking the button on the pull request page on GitHub.
To do the merge manually, you'll need to checkout the target branch in the source repo, pull directly from the fork, and then merge and push.
# Checkout the branch you're merging to in the target repo
git checkout master
# Pull the development branch from the fork repo where the pull request development was done.
git pull https://github.com/forkuser/forkedrepo.git newfeature
# Merge the development branch
git merge newfeature
# Push master with the new feature merged into it
git push origin masterNow that you're done with the development branch, you're free to delete it.
git branch -d newfeatureCopyright Copyright 2021, Chrisitne Seeman adapted from Copyright 2017, Chase Pettit
MIT License, http://www.opensource.org/licenses/mit-license.php
Additional Reading
Sources