Workflow
- assuming you are working with
gitfrom a command line - assuming your GitHub username is
username github.com/sappelhoff/pyprepisupstreamgithub.com/username/pyprepisorigin(your fork)
Syncing your fork’s master with upstream master
- first, you start with forking
upstream - then, you continue by cloning your fork:
git clone https://github.com/username/pyprep- you’ll have your own
masterbranch there
- you’ll have your own
- you always want to make sure that your fork’s
masterandupstream masterare aligned- to do this, you work with git remotes
- Note: this also means that you NEVER work on
master(unless you know what you are doing)… because you want to always be able to SYNC your fork withupstream, which would mean losing your own work onmaster
- Note: this also means that you NEVER work on
- to do this, you work with git remotes
- use
git remote -vto list your configured remotes- initially this will only list
origin… a bit like this maybe:
- initially this will only list
origin https://github.com/username/pyprep (fetch)
origin https://github.com/username/pyprep (push)
- Now you want to add
upstreamas a remote. Usegit remote add upstream https://github.com/sappelhoff/pyprep - again, do
git remote -v, it should look like this:
origin https://github.com/username/pyprep (fetch)
origin https://github.com/username/pyprep (push)
upstream https://github.com/sappelhoff/pyprep (fetch)
upstream https://github.com/sappelhoff/pyprep (push)
- Now you can use your
upstreamremote to make sure your fork’smasteris up to date.git checkout masterto make sure you are on yourmasterbranch- Make sure you do not have any changes on your
master, because we will discard them! git pull upstream masterSYNC your fork andupstream- sometimes there are issues, so to be safe, do:
git reset --hard upstream/master… this makes sure that both branches are really synced. - ensure with another
git pull upstream master… this should say “already up to date”
- Make sure you do not have any changes on your
Working on a feature (and rebasing)
Working on a feature
- before working on any feature: always do
git checkout masterandgit pull upstream master - then make your new branch to work on and check it out, for example
git checkout -b my_feature- do your work
- submit a pull request
- hope you are lucky and nobody did work in between
- do your work
- however IF somebody did work in between, we need to rebase. Just follow the steps below
Rebasing without conflicts
- sync
masterthrough:git checkout masterandgit pull upstream master - go back to your branch and rebase it:
git checkout my_featureand thengit rebase my_feature
Now it could be that you are lucky and there no conflicts… in that case, the rebase just works and you can then finish up by force pushing your rebased branch: git push -f my_feature… you need to force it, because rebasing changed the history of your branch. But don’t worry, if rebasing “just worked” without any conflicts, this should be very safe.
Rebasing WITH conflicts
In case you are unlucky, there are conflicts and you’ll have to resolve them step by step… git will be in rebase mode and try to rebase one commit after another… for each commit where conflicts are detected, it’ll stop.
Then you have to do: git status to see conflicting files… then edit these files to resolve conflicts… then git add <filename>… and then git rebase --continue to go on to the next commit, rinse and repeat.
NOTE: the conflict resolution part is the dangerous part that can get very messy and where you can actually lose stuff… so make backups of your branch before.
After everything is resolved, you can again do git push -f my_feature.
If you screw up during rebasing and you panic, you can do git rebase --abort and start again.
Rebasing… panic mode (or “the easy way”)
If nothing helps and you just don’t know how to resolve the issues and conflicts that arise during rebasing, just make a new branch: 1. git checkout master 1. git pull upstream master 1. git checkout -b my_feature_2nd_attempt
… and apply your changes manually.
This method is not really a git workflow,… but in cases where there are only few changes, this is often a practical solution.