deletions | additions       diff --git a/box-1-definitions.tex b/box-1-definitions.tex  index 5598c7e..e7f2f65 100644  --- a/box-1-definitions.tex  +++ b/box-1-definitions.tex 
...
\subsection*{Box \section*{Box  1: Definitions} \begin{itemize}  \item \textbf{Version Control System (VCS)}: \textit{(noun)} a program that tracks changes to specified files over time and maintains a library of all past versions of those files  diff --git a/box-2-what-not-to-version-control.tex b/box-2-what-not-to-version-control.tex  index c74a85f..0933002 100644  --- a/box-2-what-not-to-version-control.tex  +++ b/box-2-what-not-to-version-control.tex 
...
\subsection*{Box \section*{Box  2: What \textit{not} to version control} You \textit{can} version control any file that you put in a 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 best for plain text based documents such as your scripts or your manuscript if written in LaTeX or Markdown. This is because for text files, 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 has the capability to compare between versions (using \verb|git diff|). You can commit a non-text file, but a full copy of the file will be saved in each commit that modifies it. 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.  diff --git a/box-3-managing-large-files.tex b/box-3-managing-large-files.tex  index ac2873e..4d7263a 100644  --- a/box-3-managing-large-files.tex  +++ b/box-3-managing-large-files.tex 
...
\subsection*{Box \section*{Box  3: Managing large files} Many biological applications require handling large data files.  While Git is best-suited for collaboratively writing small text files, nonetheless collaboratively working on projects in the biological sciences necesitates managing this data.  diff --git a/box-4-licensing.tex b/box-4-licensing.tex  index e873159..6e56632 100644  --- a/box-4-licensing.tex  +++ b/box-4-licensing.tex 
...
\subsection*{Box \section*{Box  4: Choosing a license} Putting software and other material in a public place is not the same  as making it publicly usable. In order to do that, the authors must  diff --git a/box-5-being-scooped.tex b/box-5-being-scooped.tex  index cbfcfea..0a51d50 100644  --- a/box-5-being-scooped.tex  +++ b/box-5-being-scooped.tex 
...
\subsection*{Box \section*{Box  5: Being Scooped} One concern scientists frequently have about putting work in progress online is that they will be scooped, e.g., that someone will analyze their data and publish a result that they themselves would have, but hadn't yet. In practice, though, this happens rarely if at all: in fact, the authors are not aware of a single case in which this has actually happened, and would welcome pointers to specific instances. In practice, it seems more likely that making work public early in something like a version control repository, which automatically adds timestamps to content, will help researchers establish their priority.  diff --git a/box-6-sharing-policies.tex b/box-6-sharing-policies.tex  index d2a00e6..669e3cf 100644  --- a/box-6-sharing-policies.tex  +++ b/box-6-sharing-policies.tex 
...
\subsection*{Box \section*{Box  6: Journal Policies} Sharing data, code, and other materials is quickly moving from ``desired'' to ``required''.  For example, PLOS's sharing policy (\href{http://journals.plos.org/plosone/s/materials-and-software-sharing}{journals.plos.org/plosone/s/materials-and-software-sharing})  diff --git a/box-7-branching.tex b/box-7-branching.tex  index f8ec515..6268ac1 100644  --- a/box-7-branching.tex  +++ b/box-7-branching.tex 
...
\subsection*{Box \section*{Box  7: Branching} Do you ever make changes to your code, but are not sure you will want to keep those changes for your final analysis? Or do you need to implement new features while still providing a stable version of the code for others to use? Using 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, 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|git 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/conclusion.tex b/conclusion.tex  index 5a099cb..f5e419a 100644  --- a/conclusion.tex  +++ b/conclusion.tex 
...
\subsection*{Conclusion} \section*{Conclusion}  Git, albeit complicated at first, is a powerful tool that can improve code development and documentation.  Ultimately the complexity of a VCS not only gives users a well-documented ``undo'' button for their analyses, but it also allows for collaboration and sharing of code on a massive scale.  diff --git a/contribute-to-other-projects.tex b/contribute-to-other-projects.tex  index 52c3f41..f810804 100644  --- a/contribute-to-other-projects.tex  +++ b/contribute-to-other-projects.tex 
...
\subsection*{Contribute \section*{Contribute  to other projects} Lots of scientific software is hosted online in Git repositories.  Now that you know the basics of Git, you can directly contribute to developing the scientific software you use for your research (Fig. \ref{fig:Fig4}).  diff --git a/figures/figure-legends.tex b/figures/figure-legends.tex  index 3318602..3872ca4 100644  --- a/figures/figure-legends.tex  +++ b/figures/figure-legends.tex 
...
\subsection*{Figure \section*{Figure  Legends} \textbf{Figure \ref{fig:Fig1}. The git add/commit process.}  To store a snapshot of changes in your repository, first \verb|git add| any files to the staging area you wish to commit (for example, you've updated the \verb|process.sh| file).  diff --git a/introduction.tex b/introduction.tex  index aef5fff..43bafe9 100644  --- a/introduction.tex  +++ b/introduction.tex 
...
\subsection*{Introduction \section*{Introduction  to version control} Many scientists write code as part of their research.  Just as experiments are logged in laboratory notebooks, it is important to document the code you use for analysis.  diff --git a/methods.tex b/methods.tex  index 27b683a..ab285fb 100644  --- a/methods.tex  +++ b/methods.tex 
...
\subsection*{Methods} \section*{Methods}  We collaboratively wrote the article in LaTeX (\href{http://www.latex-project.org/}{latex-project.org}) using the online authoring platform Authorea (\href{https://www.authorea.com}{authorea.com}).  Furthermore, we tracked the development of the document using Git and GitHub.  diff --git a/share-your-code.tex b/share-your-code.tex  index 62ea558..771cf61 100644  --- a/share-your-code.tex  +++ b/share-your-code.tex 
...
\subsection*{Share \section*{Share  your code} Once you have your files saved in a Git repository, you can share it with your collaborators and the wider scientific community by putting your code online (Fig. \ref{fig:Fig3}).  This also has the added benefit of creating a backup of your scripts and provides a mechanism for transferring your files across multiple computers.  diff --git a/table-1-resources.tex b/table-1-resources.tex  index de37401..2be8845 100644  --- a/table-1-resources.tex  +++ b/table-1-resources.tex 
...
\subsection*{Table \section*{Table  1: Resources} \begin{tabular}{|l|l|}  \hline  diff --git a/version-your-code.tex b/version-your-code.tex  index 32938ec..bda2598 100644  --- a/version-your-code.tex  +++ b/version-your-code.tex 
...
\subsection*{Version \section*{Version  your code} The first step is to learn how to version your own code.  In this tutorial, we will run Git from the command line of the Unix shell.