diff --git a/Typical-Git-Workflow.md b/Typical-Git-Workflow.md
index 6ce5cdf..8c0baa7 100644
--- a/Typical-Git-Workflow.md
+++ b/Typical-Git-Workflow.md
@@ -1,6 +1,6 @@
 This is a guide to a typical Git workflow with Citra. It covers forking from the main repository, creating a branch, keeping your branch up to date with the main repository, resolving conflicts, and merging back into the main repository. It's not meant to be a hard-and-fast set of rules. However, if you follow something along these lines, you'll be less likely to piss people off.
 
-It's appreciated if every single commit in a branch on its own compiles on all supported platforms (Windows, Linux) and doesn't cause any regressions if the commits after it were left unmerged. We understand that with early development, sometimes it's easier to commit early-and-often, and sometimes you may unintentionally break things (and then later fix them in your branch). If this is part of your workflow, we expect appropriate use of Git rebase to squash broken commits and resolve merge conflicts. If you don't know how Git rebase works, please read [this article](http://git-scm.com/book/en/Git-Branching-Rebasing) before developing for Citra.
+It's appreciated if every single commit in a branch on its own compiles on all supported platforms (Windows, Linux, and OS X) and doesn't cause any regressions if the commits after it were left unmerged. We understand that with early development, sometimes it's easier to commit early-and-often, and sometimes you may unintentionally break things (and then later fix them in your branch). If this is part of your workflow, we expect appropriate use of Git rebase to squash broken commits and resolve merge conflicts. If you don't know how Git rebase works, please read [this article](http://git-scm.com/book/en/Git-Branching-Rebasing) before developing for Citra.
 
 **Terminology**
 * `upstream`: Main project repository (https://github.com/citra-emu/citra)