diff --git a/_episodes/14-collaboration-using-git.md b/_episodes/14-collaboration-using-git.md
index 4954d264d..a7d354704 100644
--- a/_episodes/14-collaboration-using-git.md
+++ b/_episodes/14-collaboration-using-git.md
@@ -57,11 +57,11 @@ Git has several important characteristics:
so even if you make a mistake you can revert to a point before it.
The diagram below shows a typical software development lifecycle with Git
-and the commonly used commands to interact
-with different parts of Git infrastructure,
+(starting from making changes locally) and the commonly used commands to interact
+with different parts of the Git infrastructure,
such as:
- **working directory** -
- a directory (including any subdirectories) where your project files live
+ a local directory (including any subdirectories) where your project files live
and where you are currently working.
It is also known as the “untracked” area of Git.
Any changes to files will be marked by Git in the working directory.
@@ -72,32 +72,50 @@ such as:
- **staging area (index)** -
once you tell Git to start tracking changes to files
(with `git add filename` command),
- Git saves those changes in the staging area.
+ Git saves those changes in the staging area on your local machine.
Each subsequent change to the same file needs to be followed by another `git add filename` command
to tell Git to update it in the staging area.
To see what is in your working directory and staging area at any moment
(i.e. what changes is Git tracking),
run the command `git status`.
- **local repository** -
- stored within the `.git` directory of your project,
+ stored within the `.git` directory of your project locally,
this is where Git wraps together all your changes from the staging area
and puts them using the `git commit` command.
Each commit is a new, permanent snapshot (checkpoint, record) of your project in time,
- which you can share or revert back to.
+ which you can share or revert to.
- **remote repository** -
this is a version of your project that is hosted somewhere on the Internet
- (e.g. on GitHub, GitLab or somewhere else).
+ (e.g., on GitHub, GitLab or somewhere else).
While your project is nicely version-controlled in your local repository,
and you have snapshots of its versions from the past,
- if your machine crashes - you still may lose all your work.
- Working with a remote repository involves pushing your changes
- and pulling other people's changes to keep your local repository in sync
- in order to collaborate with others and to backup your work on a different machine.
-
-{: .image-with-shadow width="600px"}
+ if your machine crashes - you still may lose all your work. Furthermore, you cannot
+ share or collaborate on this local work with others easily.
+ Working with a remote repository involves pushing your local changes remotely
+ (using `git push`) and pulling other people's changes from a remote repository to
+ your local copy (using `git fetch` or `git pull`) to keep the two in sync
+ in order to collaborate (with a bonus that your work also gets backed up to another machine).
+ Note that a common best practice when collaborating with others on a shared repository
+ is to always do a `git pull` before a `git push`, to ensure you have any latest changes before you push your own.
+
+
+
+{: .image-with-shadow width="600px"}
-Software development lifecycle with Git from PNGWing
-{%comment%} (licenced for non-commercial reuse){%endcomment%}
+Software development lifecycle with Git
## Checking-in Changes to Our Project
diff --git a/fig/git-lifecycle.png b/fig/git-lifecycle.png
deleted file mode 100644
index 9f57d1ca5..000000000
Binary files a/fig/git-lifecycle.png and /dev/null differ
diff --git a/fig/git-lifecycle.svg b/fig/git-lifecycle.svg
new file mode 100644
index 000000000..493c15367
--- /dev/null
+++ b/fig/git-lifecycle.svg
@@ -0,0 +1,592 @@
+
+