An abbreviated guide to the Git squash-and-rebase workflow with relevant commands

abbreviated-squash-and-rebase-workflow.sh

# Github fork button
git clone <my-fork-url>
git remote add upstream <original-repo-url>
# check remotes are both configured
git remote -v

# Time to work

# update your master branch
git fetch upstream master # git fetch upstream will grab all branches
git checkout master
git merge upstream/master

# Do your work
git checkout -b my-fix
# work work work

# squash
# find the SHA of the master commit your branch branches from
git log
# squash to 1 commit
# squash recent commits into the oldest one and reword if you want
git rebase -i <SHA before the one you want to squash into>
git push -f origin my-fix

# update your master branch
git fetch upstream master
git checkout master
git merge upstream/master

# rebase your branch from master
git checkout my-fix
git rebase master
# handle any conflicts
# re-test your code
git push -f origin my-fix

# if you own the repo
git checkout master
git merge my-fix
git push origin master

# if you're submitting a PR
# select my-fix branch from your Github fork repo
# click the pull request button and follow steps

# accepting someone else's PR
# open .gitconfig
# add fetch = +refs/pull/*/head:refs/pull/origin/* under [remote "origin"]
#   ASIDE: Pro Git says add
#   fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
#   it turns out that the 2nd part is the local path you want, so it's up to you
# this allows you to fetch PRs
# fetch all PR branches
git fetch origin
# or list them to pick a particular one
git branch -va
git checkout -b my-fix pull/origin/my-fix
# Pro Git just checks out origin/pr/2 as `git checkout pr/2` so presumably it's just a question of whether you want to give it a new name.
# the branch will be read-only
# if the branch merges with a FF, you can merge it from the Github PR page with a click

# manual merging (if you haven't altered gitconfig as above)
git checkout master
git pull https://github.com/someuser/forked-repo-name my-fix # seems like this should be `fetch` - you need to clarify that - why would pull not automatically merge in this case?
# if the submitting user didn't squash, you could checkout their branch and do it here, but assuming they did, stay on master and merge it
git merge my-fix
git push origin master
git branch -d my-fix

---

# NOTE: Pro Git actually recommends against this approach. An alternative approach is to simply merge the target branch into your feature branch and leave all the history messy with the merge commit:
git fetch upstream
git checkout -b my-fix
git merge upstream/master
# handle any conflicts
git commit -a -m 'merge upstream/master'
git push -u my-fix
# send PR