git-guides: use en dash instead of hyphen (#878)

English typography typically uses dashes: either spaced en dash (an en
dash surrounded by spaces) or an unspaced em dash are used.

Use a spaced en dash in all instances in git-guides, where hyphen is
currently used between words in prose, but a dash is more appropriate.

Author: rybak

git-guides/git-add.md

@@ -2,7 +2,7 @@
 
 The `git add` command adds new or changed files in your working directory to the Git staging area.
 
-`git add` is an important command - without it, no `git commit` would ever do anything. Sometimes, `git add` can have a reputation for being an unnecessary step in development. But in reality, `git add` is an important and powerful tool. `git add` allows you to shape history without changing how you work.
+`git add` is an important command – without it, no `git commit` would ever do anything. Sometimes, `git add` can have a reputation for being an unnecessary step in development. But in reality, `git add` is an important and powerful tool. `git add` allows you to shape history without changing how you work.
 
 ![image of working directory, staging area, and committed history with commands shown and visualized]()
 
@@ -12,7 +12,7 @@ The `git add` command adds new or changed files in your working directory to the
 git add README.md
 ```
 
-As you're working, you change and save a file, or multiple files. Then, before you commit, you must `git add`. This step allows you to choose what you are going to commit. Commits should be logical, atomic units of change - but not everyone works that way. Maybe you are making changes to files that _aren't_ logical or atomic units of change.  `git add` allows you to systematically shape your commits and your history anyway.
+As you're working, you change and save a file, or multiple files. Then, before you commit, you must `git add`. This step allows you to choose what you are going to commit. Commits should be logical, atomic units of change – but not everyone works that way. Maybe you are making changes to files that _aren't_ logical or atomic units of change.  `git add` allows you to systematically shape your commits and your history anyway.
 
 ### What Does Git Add Do?
 

git-guides/git-clone.md

@@ -10,7 +10,7 @@ Git is a distributed version control system. Maximize the advantages of a full r
 git clone https://github.com/github/training-kit.git
 ```
 
-When you clone a repository, you don't get one file, as you may in other centralized version control systems. By cloning with Git, you get the entire repository - all files, all branches, and all commits.
+When you clone a repository, you don't get one file, as you may in other centralized version control systems. By cloning with Git, you get the entire repository – all files, all branches, and all commits.
 
 Cloning a repository is typically only done once, at the beginning of your interaction with a project. Once a repository already exists on a remote, like on GitHub, then you would clone that repository so you could interact with it locally. Once you have cloned a repository, you won't need to clone it again to do regular development.
 
@@ -57,7 +57,7 @@ _Cloning only one branch does not add any benefits unless the repository is very
 
 Depending on how you authenticate with the remote server, you may choose to clone using SSH.
 
-If you choose to clone with SSH, you would use a specific SSH path for the repository instead of a URL. Typically, developers are authenticated with SSH from the machine level. This means that you would probably clone with HTTPS or with SSH - not a mix of both for your repositories.
+If you choose to clone with SSH, you would use a specific SSH path for the repository instead of a URL. Typically, developers are authenticated with SSH from the machine level. This means that you would probably clone with HTTPS or with SSH – not a mix of both for your repositories.
 
 ## Related Terms
 

git-guides/git-commit.md

@@ -18,7 +18,7 @@ Commits are lightweight SHA hashes, objects within Git. As long as you're workin
 
 ### Committing in two phases
 
-Commits have two phases to help you craft commits properly. Commits should be logical, atomic units of change that represent a specific idea. But, not all humans work that way. You may get carried away and end up solving two or three problems before you remember to commit! That's OK - Git can handle that. Once you're ready to craft your commits, you'll use `git add <FILENAME>` to specify the files that you'd like to "stage" for commit. Without adding any files, the command `git commit` won't work. Git only looks to the staging area to find out what to commit. Staging, or adding, files, is possible through the command line, and also possible with most Git interfaces like GitHub Desktop by selecting the lines or files that you'd like to stage.
+Commits have two phases to help you craft commits properly. Commits should be logical, atomic units of change that represent a specific idea. But, not all humans work that way. You may get carried away and end up solving two or three problems before you remember to commit! That's OK – Git can handle that. Once you're ready to craft your commits, you'll use `git add <FILENAME>` to specify the files that you'd like to "stage" for commit. Without adding any files, the command `git commit` won't work. Git only looks to the staging area to find out what to commit. Staging, or adding, files, is possible through the command line, and also possible with most Git interfaces like GitHub Desktop by selecting the lines or files that you'd like to stage.
 
 You can also use a handy command, `git add -p`, to walk through the changes and separate them, even if they're in the same file.
 
@@ -42,7 +42,7 @@ Sometimes, you may need to change history. You may need to undo a commit. If you
 
 ### What can go wrong while changing history?
 
-Changing history for collaborators can be problematic in a few ways. Imagine - You and another collaborator have the same repository, with the same history. But, they make a change that _deletes_ the most recent commit. They continue new commits from the commit directly before that. Meanwhile, you keep working _with_ the commit that the collaborator tried to delete. When they push, they'll have to 'force push', which should show to them that they're changing history. **What do you think will happen when you try to push?**
+Changing history for collaborators can be problematic in a few ways. Imagine – You and another collaborator have the same repository, with the same history. But, they make a change that _deletes_ the most recent commit. They continue new commits from the commit directly before that. Meanwhile, you keep working _with_ the commit that the collaborator tried to delete. When they push, they'll have to 'force push', which should show to them that they're changing history. **What do you think will happen when you try to push?**
 
 In dramatic cases, Git may decide that the histories are too different and the projects are no longer related. This is uncommon, but a big problem.
 
@@ -54,11 +54,11 @@ The most common result is that your `git push` would return the "deleted" commit
 
 #### `git reset`
 
-Sometimes, a commit includes sensitive information that actually needs to be deleted. `git reset` is a very powerful command that may cause you to lose work. By resetting, you move the `HEAD` pointer and the branch pointer to another point in time - maybe making it seem like the commits in between never happened! Before using `git reset`:
+Sometimes, a commit includes sensitive information that actually needs to be deleted. `git reset` is a very powerful command that may cause you to lose work. By resetting, you move the `HEAD` pointer and the branch pointer to another point in time – maybe making it seem like the commits in between never happened! Before using `git reset`:
 
 - Make sure to talk with your team about any shared commits
 - Research the three types of reset to see which is right for you (--soft, --mixed, --hard)
-- Commit any work that you don't want to be lost intentionally - work that is committed can be gotten back, but uncommitted work cannot
+- Commit any work that you don't want to be lost intentionally – work that is committed can be gotten back, but uncommitted work cannot
 
 #### `git reflog`
 

git-guides/git-init.md

@@ -8,7 +8,7 @@ git init
 
 ## What Does `git init` Do?
 
-`git init` is one way to start a new project with Git. To start a repository, use either `git init` or `git clone` - not both.
+`git init` is one way to start a new project with Git. To start a repository, use either `git init` or `git clone` – not both.
 
 To initialize a repository, Git creates a hidden directory called `.git`. That directory stores all of the objects and refs that Git uses and creates as a part of your project's history. This hidden `.git` directory is what separates a regular directory from a Git repository.
 

git-guides/git-overview.md

@@ -23,7 +23,7 @@ Everything you need to know about Git, from getting started to advanced commands
 
 ## What is Git?
 
-Git is a distributed version control software. Version control is a way to save changes over time without overwriting previous versions. Being distributed means that every developer working with a Git repository has a copy of that entire repository - every commit, every branch, every file. If you're used to working with centralized version control systems, this is a big difference!
+Git is a distributed version control software. Version control is a way to save changes over time without overwriting previous versions. Being distributed means that every developer working with a Git repository has a copy of that entire repository – every commit, every branch, every file. If you're used to working with centralized version control systems, this is a big difference!
 
 Whether or not you've worked with version control before, there are a few things you should know before getting started with Git:
 
@@ -37,9 +37,9 @@ The tools that make up the core Git distribution are written in C, Shell, Perl,
 
 ## Why Use Git?
 
-Version control is very important - without it, you risk losing your work. With Git, you can make a "commit", or a save point, as often as you'd like. You can also go back to previous commits. This takes the pressure off of you while you're working. Commit often and commit early, and you'll never have that gut-sinking feeling of overwriting or losing changes.
+Version control is very important – without it, you risk losing your work. With Git, you can make a "commit", or a save point, as often as you'd like. You can also go back to previous commits. This takes the pressure off of you while you're working. Commit often and commit early, and you'll never have that gut-sinking feeling of overwriting or losing changes.
 
-There are many version control systems out there - but Git has some major advantages.
+There are many version control systems out there – but Git has some major advantages.
 
 ### Speed
 
@@ -92,7 +92,7 @@ There are _many_ ways to use Git, which doesn't necessarily make it easier! But,
 
 #### Create a branch
 
-The main branch is usually called `main`. We want to work on _another_ branch, so we can make a pull request and make changes safely. To get started, create a branch off of `main`. Name it however you'd like - but we recommend naming branches based on the function or feature that will be the focus of this branch. One person may have several branches, and one branch may have several people collaborate on it - branches are for a purpose, not a person. Wherever you currently "are" (wherever HEAD is pointing, or whatever branch you're currently "checked out" to) will be the parent of the branch you create. That means you can create branches from other branches, tags, or any commit! But, the most typical workflow is to create a branch from `main` - which represents the most current production code.
+The main branch is usually called `main`. We want to work on _another_ branch, so we can make a pull request and make changes safely. To get started, create a branch off of `main`. Name it however you'd like – but we recommend naming branches based on the function or feature that will be the focus of this branch. One person may have several branches, and one branch may have several people collaborate on it – branches are for a purpose, not a person. Wherever you currently "are" (wherever HEAD is pointing, or whatever branch you're currently "checked out" to) will be the parent of the branch you create. That means you can create branches from other branches, tags, or any commit! But, the most typical workflow is to create a branch from `main` – which represents the most current production code.
 
 #### Make changes (and make a commit)
 
@@ -106,15 +106,15 @@ Once you've saved and staged the changes, you're ready to [make the commit](/git
 
 #### Push your changes to the remote
 
-So far, if you've made a commit locally, you're the only one that can see it. To let others see your work and begin collaboration, you should "push" your changes using `git push`. If you're pushing from a branch for the first time that you've created locally, you may need to give Git some more information. `git push -u origin [branch-name]` tells Git to push the current branch, and create a branch on the remote that matches it with the same name - and also, create a relationship with that branch so that `git push` will be enough information in the future.
+So far, if you've made a commit locally, you're the only one that can see it. To let others see your work and begin collaboration, you should "push" your changes using `git push`. If you're pushing from a branch for the first time that you've created locally, you may need to give Git some more information. `git push -u origin [branch-name]` tells Git to push the current branch, and create a branch on the remote that matches it with the same name – and also, create a relationship with that branch so that `git push` will be enough information in the future.
 
 By default, `git push` only pushes the branch that you've currently checked out to.
 
 Sometimes, if there has been a new commit on the branch on the _remote_, you may be blocked from pushing. Don't worry! Start with a simple [`git pull`](/git-guides/git-pull) to incorporate the changes on the remote into your own local branch, resolve any conflicts or finish the merge from the remote into the local branch, and then try the push again.
 
 #### Open a pull request
 
-Pushing a branch, or new commits, to a remote repository is enough if a pull request already exists, but if it's the first time you're pushing that branch, you should open a new pull request. A pull request is a comparison of two branches - typically `main`, or the branch that the feature branch was created from, and the feature branch. This way, like branches, pull requests are scoped around a specific function or addition of work, rather than the person making the changes or the amount of time the changes will take.
+Pushing a branch, or new commits, to a remote repository is enough if a pull request already exists, but if it's the first time you're pushing that branch, you should open a new pull request. A pull request is a comparison of two branches – typically `main`, or the branch that the feature branch was created from, and the feature branch. This way, like branches, pull requests are scoped around a specific function or addition of work, rather than the person making the changes or the amount of time the changes will take.
 
 Pull requests are the powerhouse of GitHub. Integrated tests can automatically run on pull requests, giving you immediate feedback on your code. Peers can give detailed code reviews, letting you know if there are changes to make, or if it's ready to go.
 

git-guides/git-pull.md

@@ -31,7 +31,7 @@ If you do use `git fetch` instead of `git pull`, make sure you remember to `git
 * `git pull`: Update your local working branch with commits from the remote, _and_ update all remote tracking branches.
 * `git pull --rebase`: Update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit.
 * `git pull --force`: This option allows you to force a fetch of a specific remote tracking branch when using the `<refspec>` option that would otherwise not be fetched due to conflicts. To force Git to overwrite your current branch to match the remote tracking branch, read below about using `git reset`.
-* `git pull --all`: Fetch _all_ remotes - this is handy if you are working on a fork or in another use case with multiple remotes.
+* `git pull --all`: Fetch _all_ remotes – this is handy if you are working on a fork or in another use case with multiple remotes.
 
 You can see all of the many options with `git pull` in [git-scm's documentation](https://git-scm.com/docs/git-pull).
 
@@ -41,7 +41,7 @@ You can see all of the many options with `git pull` in [git-scm's documentation]
 
 If you're already working on a branch, it is a good idea to run `git pull` before starting work and introducing new commits. Even if you take a small break from development, there's a chance that one of your collaborators has made changes to your branch. This change could even come from updating your branch with new changes from `main`.
 
-It is always a good idea to run `git status` - especially before `git pull`. Changes that are not committed can be overwritten during a `git pull`. Or, they can block the `git merge` portion of the `git pull` from executing. If you have files that are changed, but not committed, and the changes on the remote also change those same parts of the same file, Git must make a choice. Since they are not committed changes, there is no possibility for a merge conflict. Git will either overwrite the changes in your working or staging directories, or the `merge` will not complete, and you will not be able to include any of the updates from the remote.
+It is always a good idea to run `git status` – especially before `git pull`. Changes that are not committed can be overwritten during a `git pull`. Or, they can block the `git merge` portion of the `git pull` from executing. If you have files that are changed, but not committed, and the changes on the remote also change those same parts of the same file, Git must make a choice. Since they are not committed changes, there is no possibility for a merge conflict. Git will either overwrite the changes in your working or staging directories, or the `merge` will not complete, and you will not be able to include any of the updates from the remote.
 
 If this happens, use `git status` to identify what changes are causing the problem. Either delete or commit those changes, then `git pull` or `git merge` again.
 
@@ -53,9 +53,9 @@ For example, let's say you have cloned a repository. After you clone, someone me
 
 ### Undo A `git pull`
 
-To effectively "undo" a `git pull`, you cannot undo the `git fetch` - but you can undo the `git merge` that changed your local working branch.
+To effectively "undo" a `git pull`, you cannot undo the `git fetch` – but you can undo the `git merge` that changed your local working branch.
 
-To do this, you will need to `git reset` to the commit you made _before_ you merged. You can find this commit by searching the `git reflog`. The reflog is a log of every place that HEAD has pointed - every place that you have ever been checked out to. This reflog is only kept for 30 to 90 days, depending on the commit, and is only stored locally. *(The reflog is a great reason not to delete a repository if you think you've made a mistake!)*
+To do this, you will need to `git reset` to the commit you made _before_ you merged. You can find this commit by searching the `git reflog`. The reflog is a log of every place that HEAD has pointed – every place that you have ever been checked out to. This reflog is only kept for 30 to 90 days, depending on the commit, and is only stored locally. *(The reflog is a great reason not to delete a repository if you think you've made a mistake!)*
 
 Run `git reflog` and search for the commit that you would like to return to. Then, run `git reset --hard <SHA>` to reset HEAD and your current branch to the SHA of the commit from before the merge.