Update how_to_use_git.md

documentation/how_to_use_git.md

@@ -88,6 +88,12 @@ Once you have fixed everything, `git add` those changes and `git commit` to
 create a merge commit. Maybe do another `git log` after everything to be sure
 everything makes sense.
 
+In the event that the conflicts are too confusing and you want to abort or
+start over.
+```
+git merge --abort
+```
+
 Once you have synced your master with Gitlab's master again, sync Gitlab's
 master with your master again:
 ```
@@ -117,3 +123,86 @@ get your first merge conflicts 😉
 What we just described is the bare minimum Git workflow. Most people don't like
 working this way. We encourage you to research other workflows, like a Git
 branching workflow.
+
+## Branching Workflow
+The idea behind a branching workflow is that you would have a safe, isolated
+environment to make your changes that no one else will disturb. It also prepares
+your changes for a merge request in the future that can be reviewed by the team
+before merging to master.
+
+To begin, confirm that you have no changes in progress and that you are on the
+master branch.
+
+```
+git status
+git branch
+```
+
+The status command should indicate nothing. If you do have changes, commit them,
+stash them, or discard them.
+
+The branch commdn should indicate that you are on the master branch. If not
+switch to it now.
+
+```
+git checkout master
+```
+
+Now let's be sure we are starting with the most recent version of master.
+```
+git pull origin master
+```
+
+At this point, we are ready to begin. 
+
+Create a branch for yourself, ideally named according to fix or feature that
+this branch is supposed to implement.
+
+```
+git checkout -b name-of-my-branch
+```
+
+Notice that your branch has changed:
+
+```
+git branch
+```
+
+Now you can make edits and commits as you normally would.
+
+It's good practice to update the remote repository with a copy of your branch.
+You should periodically push it once you have made some commits, and definitely
+once your are finished with the fix or feature associated with this branch.
+```
+git push origin name-of-my-branch
+```
+
+At this point, the branch should be on Gitlab, and you can open a merge request
+to have this branch merged into master. You can safely keep committing to this
+branch and pushing it to the remote after making a merge request, and the most
+recent changes will be automatically updated to the merge request.
+
+Occasionally, your merge request might be ineligible to merge if there would be
+merge conflicts. In that case, you'll have to resolve the merge conflicts
+locally before the merge request can be accepted.
+
+While on your branch (and when there are no current changes)
+```
+git pull origin master
+```
+
+This will merge the remote master into your branch. If there are merge conflicts
+you'll resolve them at this time. When finished, push the changes again to the
+remote, and the merge request should be eligible for acceptance.
+
+```
+git push origin name-of-my-branch
+```
+
+Once your merge request has been accepeted on Gitlab, you can simply delete this
+branch locally. (You'll need to be on the master branch to do that.)
+
+```
+git branch -d name-of-my-branch
+```
+