Authorea

John Blischak Use \label for managing figure labeling. almost 9 years ago

Commit id: 9af265c8a9cd9f6abfa2f7ade467ea4f82ded828

deletions | additions

$ git clone https://github.com/scientist123/cool_project.git \end{lstlisting} After making the edits you want, you can add, commit, and push the changes back to your remote repository on GitHub (Figure 3). (\label{fig:Fig3}). \begin{lstlisting} $ git add README

To merge this change into the main repository that is owned by the creator of the software, send a pull request using the GitHub interface (Pull request -\textgreater New pull request -\textgreater Create pull request). After the pull request is created, the owner of the original repository can review your change. If she approves of the change, she can merge it into the main repository. Although this process of forking a project’s repository and issuing a pull request seems like a lot of work to contribute changes, this workflow gives the owner of the project control over what changes get incorporated into the code. You can have others contribute to your projects using the same workflow (S1 Figure). (\label{fig:S1_Fig}). The ability to use Git to contribute changes is very powerful because it allows you to improve the software that is used by many other scientists and also potentially shape the future direction of its development.

\label{fig:Fig1} \textbf{\label{fig:Fig1}}

\textbf{Figure 2} \textbf{\label{fig:Fig2}}

\textbf{Figure 3} \textbf{\label{fig:Fig3}}

\textbf{S1 Figure} \textbf{\label{fig:S1_Fig}}

Second, type \verb|git commit| with a message. Only files added to the staging area will be committed. All past commits are located in the hidden \verb|.git| directory in your repository. \textbf{Figure 2. \textbf{\label{fig:Fig2}}. Working with both a local and remote repository as a single user.} A) On your computer you commit to a Git repository (commit d75es). B) On GitHub, you create a new repository called \verb|thesis|. This repository is currently empty and not linked to the repo on your local machine.

F) To sync the local and remote repositories, you \verb|git push| the two new commits to the remote repository. The local and remote repositories now contain the same files and commit histories. \textbf{Figure 3. \textbf{\label{fig:Fig3}. Contributing to Open Source Projects.} You found an error in the README for a cool project hosted on GitHub and you would like to fix it. A) The cool\_project repository exists on GitHub (along with the commit history of the project), but you would like to edit the README on your computer. B) First, you fork the cool\_project repository into your account on GitHub, bringing the entire commit history of the project along with the code.

F) To suggest the change in the README to the original cool\_project team, submit a pull request via GitHub. If the owner(s) of the cool\_project repository like your change, they will accept the pull request and your changes will be incorporated into the project. \textbf{S1 Figure. \textbf{\label{fig:S1_Fig}. Collaboration using GitHub.} A) You have a repository on your computer and on GitHub that you have already connected using \verb|git remote add|, but you have not pushed any content to the remote repo yet. B) You push your local commits to your remote repository using \verb|git push| (both your local and your remote have commit d75es). C) Your collaborator would like to help you analyze your data.

The name "origin" is a bookmark for the remote repository so that you do not have to type out the full URL every time you sync your changes (this is the default name for a remote repository, but you could use another name if you liked). Send your code to GitHub using the command \verb|git push| (Figure 2). (\label{fig:Fig2}). \begin{lstlisting} $ git push origin master

Conceptually, Git saves snapshots of the changes you make to your files whenever you instruct it to. For instance, after you edit a script in your text editor, you save the updated script to your thesis folder. If you tell Git to save a shapshot of the updated document, then you will have a permanent record of the file in that exact version even if you make subsequent edits to the file. In the Git framework, any changes you have made to a script, but have not yet recorded as a snapshot with Git, reside in the working diretory (Figure 1). (\label{fig:Fig1}). To follow what Git is doing as you record the initial version of your files, use the informative command \verb|git status|. \begin{lstlisting}

\end{lstlisting} Now the file \verb|process.sh| has been added to the staging area, while both \verb|clean.py| and \verb|analyze.R| remain unstaged. Adding a file to the staging area will result in the changes to that file being included in the next commit, or snapshot of the code (Figure 1). (\label{fig:Fig1}). As an analogy, adding files to the staging area is like putting things in a box to mail off, and committing is like putting the box in the mail. Since this will be the first commit, or first version of the code, add the other two files to the staging area as well.