Merge branch 'gh-pages' of github.com:swcarpentry/git-novice into update-zenodo-json

Author: tobyhodges

_episodes/02-setup.md

@@ -138,15 +138,24 @@ $ git config --global init.defaultBranch main
 The five commands we just ran above only need to be run once: the flag `--global` tells Git
 to use the settings for every project, in your user account, on this computer.
 
-You can check your settings at any time:
+Let's review those settings and test our `core.editor` right away:
+
+~~~
+$ git config --global --edit
+~~~
+{: .language-bash}
+
+Let's close the file without making any additional changes.  Remember, since typos in the config file will cause 
+issues, it's safer to view the configuration with:
 
 ~~~
 $ git config --list
 ~~~
 {: .language-bash}
 
-You can change your configuration as many times as you want: use the
+And if necessary, change your configuration using the
 same commands to choose another editor or update your email address.
+This can be done as many times as you want.
 
 > ## Proxy
 >

_episodes/09-conflict.md

@@ -314,6 +314,7 @@ consider these technical approaches to reducing them:
 - Pull from upstream more frequently, especially before starting new work
 - Use topic branches to segregate work, merging to main when complete
 - Make smaller more atomic commits
+- Push your work when it is done and encourage your team to do the same to reduce work in progress and, by extension, the chance of having conflicts
 - Where logically appropriate, break large files into smaller ones so that it is
   less likely that two authors will alter the same file simultaneously
 

_episodes/10-open.md

@@ -21,22 +21,22 @@ but the reality is often more complicated.
 Normal practice today looks something like this:
 
 *   A scientist collects some data and stores it on a machine
-    that is occasionally backed up by her department.
-*   She then writes or modifies a few small programs
-    (which also reside on her machine)
+    that is occasionally backed up by their department.
+*   They then write or modify a few small programs
+    (which also reside on the machine)
     to analyze that data.
-*   Once she has some results,
-    she writes them up and submits her paper.
-    She might include her data -- a growing number of journals require this -- but
-    she probably doesn't include her code.
+*   Once they have some results,
+    they write them up and submit a paper.
+    The scientist might include their data -- a growing number of journals require this -- but
+    they probably don't include the code.
 *   Time passes.
-*   The journal sends her reviews written anonymously by a handful of other people in her field.
-    She revises her paper to satisfy them,
-    during which time she might also modify the scripts she wrote earlier,
+*   The journal sends the scientist reviews written anonymously by a handful of other people in their field.
+    The scientist revises the paper to satisfy the reviewers,
+    during which time they might also modify the scripts they wrote earlier,
     and resubmits.
 *   More time passes.
 *   The paper is eventually published.
-    It might include a link to an online copy of her data,
+    It might include a link to an online copy of the data,
     but the paper itself will be behind a paywall:
     only people who have personal or institutional access
     will be able to read it.
@@ -52,24 +52,24 @@ the process looks like this:
     [Digital Object Identifier](https://en.wikipedia.org/wiki/Digital_object_identifier) (DOI).
     Or the data was already published and is stored in
     [Dryad](https://datadryad.org/).
-*   The scientist creates a new repository on GitHub to hold her work.
-*   As she does her analysis,
-    she pushes changes to her scripts
+*   The scientist creates a new repository on GitHub to hold their work.
+*   During analysis,
+    they push changes to their scripts
     (and possibly some output files)
     to that repository.
-    She also uses the repository for her paper;
-    that repository is then the hub for collaboration with her colleagues.
-*   When she's happy with the state of her paper,
-    she posts a version to [arXiv](https://arxiv.org/)
+    The scientist also uses the repository for their paper;
+    that repository is then the hub for collaboration with colleagues.
+*   When they are happy with the state of the paper,
+    the scientist posts a version to [arXiv](https://arxiv.org/)
     or some other preprint server
     to invite feedback from peers.
 *   Based on that feedback,
-    she may post several revisions
-    before finally submitting her paper to a journal.
-*   The published paper includes links to her preprint
-    and to her code and data repositories,
+    they may post several revisions
+    before finally submitting the paper to a journal.
+*   The published paper includes links to the preprint
+    and to the code and data repositories,
     which  makes it much easier for other scientists
-    to use her work as starting point for their own research.
+    to use their work as starting point for their own research.
 
 This open model accelerates discovery:
 the more open work is,

setup.md

@@ -3,9 +3,15 @@ layout: page
 title: Setup
 ---
 
-Please see [this section of the workshop template][workshop-setup]
-for instructions on installing Git.
+## Installing Git
+Since several Carpentries lessons rely on Git, please see
+[this section of the workshop template][workshop-setup] for
+instructions on installing Git for various operating systems.
+- [Git installation on Windows][workshop-setup]
+- [Git installation on MacOS][workshop-setup]
+- [Git installation on Linux][workshop-setup]
 
+## Preparing Your Working Directory
 We'll do our work in the `Desktop` folder so make sure you change your working directory to it with:
 
 ~~~