deletions | additions       diff --git a/box-1-definitions.tex b/box-1-definitions.tex  index ec71bf0..a078bf7 100644  --- a/box-1-definitions.tex  +++ b/box-1-definitions.tex 
...
\subsection{Box 1: Definitions}  \begin{itemize}  \item \textbf{git}: \textbf{Git}:  \textit{(noun)} a version control system; \textit{(verb)} command used to run all version control processes system  \item \textbf{repository (repo)}: \textit{(noun)} folder containing all items to be version controlled tracked files  as well as the version control history \item \textbf{commit}: \textit{(noun)} a snapshot of changes made to a the  staged file or files; file(s);  \textit{(verb)} to save a snapshot of changes made to the  staged files file(s)  \item \textbf{branch}: \textit{(noun)} a parallel version of your the files in a  repository which separately version controlled (Box 2)  \item \textbf{local}: \textit{(noun)} the version of your repository that is stored on your personal computer  \item \textbf{remote}: \textit{(noun)} the version of your repository that is stored on the internet, for instance on github.com GitHub  \item \textbf{clone}:\textit{(noun)} a copy of a remote repository, made on your personal computer;  \textit{(verb)} to create a local  copy of a remote repository on your personal computer \item \textbf{fork}: \textit{(noun)} a copy of someone else's remote repository into your account; a repository;  \textit{(verb)} to copy someone else's remote a  repositoryinto your account  \item \textbf{merge}: \textit{(verb)} to combine different versions of update  files from two branches into one branch by incorporating the changes introduced in new commits  \item \textbf{pull}: \textit{(verb)} to incorporate the retrieve  commits made to from  a remote repository that are not in and merge them into  a local repositoryautomatically  \item \textbf{push}: \textit{(verb)} to send commits from a local repository to a remote repository  \item \textbf{pull request}: \textit{(noun)} a message sent by one user to merge the commits in  their remote repository into another users user's  remote repository \end{itemize}  diff --git a/box-2-branching.tex b/box-2-branching.tex  index 701216e..3334845 100644  --- a/box-2-branching.tex  +++ b/box-2-branching.tex 
...
\subsection{Box 2: Branching}  Do you ever make changes to your code, but are not sure you will want to keep those changes for your final analysis? Using git, Git,  you can maintain parallel versions of your code that you can easily bounce between while you are working on your changes. You can think of it like making a copy of the folder you keep your scripts in, so that you have your original scripts intact but also have the new folder where you make changes. Using git, Git,  this is called branching and it is better than separate folders because 1) it uses a fraction of the space on your computer, 2) keeps a record of when you made the parallel copy (branch) and what you have done on the branch, and 3) there is a way to incorporate those changes back into your main code if you decide to keep your changes (and a way to deal with conflicts). By default, your repository will start with one branch, usually called "master". To create a new branch in your repository, type \verb|git branch new_branch_name|. You can see what branches a current repository has by typing \verb|git branch|, with the branch you are currently in being marked by a star. To move between branches, type \verb|gitbranch  checkout branch_to_move_to|. You can edit files and commit them on each branch separately. If you want combine the changes in your new branch with the master branch, you can merge the branches by typing \verb|git merge new_branch_name| while in the master branch. diff --git a/box-3-what-not-to-version-control.tex b/box-3-what-not-to-version-control.tex  index 693ea06..4070c05 100644  --- a/box-3-what-not-to-version-control.tex  +++ b/box-3-what-not-to-version-control.tex 
...
\subsection{Box 3: What \textit{not} to version control}  You \textit{can} version control any file that you put in a git Git  repository, whether it is text-based, an image, or giant data files. However, just because you \textit{can} version control something, does not mean you \textit{should}. Git works great best  for plain text based documents such as your scripts or your manuscript if written in latex LaTeX  or markdown. Markdown.  This is because for text files, git Git  saves the entire file only the first time you commit it and then saves just your changes with each commit. This takes up very little space and git Git  has the capabilities capability  to compare between versionsbuilt in  (using \verb|git diff|). You can commit a non-text file, but a full copy of the file will be saved with each commit. Over time, you may find the size of your repository growing very quickly. A good rule of thumb is to version control anything text based: your scripts or manuscripts if they are written in plain text. Things \textit{not} to version control are large data files that never change, binary files (including Word and Excel documents), and the output of your code.