Short version of the git rebase workflow I usually use.

git rebase workflow

# Mostly from http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
# See also https://github.com/thoughtbot/guides/blob/master/protocol/git/README.md

# Make a branch called feature_name

git checkout -b feature_name

# Assuming we are working in a branch called "feature_name”.
# Rebase against master frequently (maybe daily, or whenever you're at
# a good stopping point), to avoid conflicts at the end:

git fetch origin
git rebase origin/master

# Squash commits to make it nicer. Do this (usually) before creating
# PR, and *always* when it's time to bring this all back to master:

git rebase -i origin/master
# [Use vim to clean up the history, save]

# Now you have a crazy-looking git status like this:
#    Your branch and 'origin/Enterprise' have diverged,
#    and have 1 and 4 different commits each, respectively.
#      (use "git pull" to merge the remote branch into yours)

# Don’t follow the advice to “pull”, you’ll just sort of undo what you’ve done.
# Instead, force push the branch, so github can close PR and mark as merged
# automatically later

git push --force origin feature_name

# Create a PR, and get whatever feedback you need on the PR to make sure this
# branch’s content is acceptable. If you have to make changes, then commit
# them and squash them as shown above.

# Now that our branch is freshly-rebased on master, this is how to bring all the
# changes back there.
git checkout master
git merge feature_name --ff-only
git push

# delete the remote branch, then the local
git push origin --delete feature_name
git branch --delete feature_name