Automated Version Control


Figure 1

“Piled Higher and Deeper” by Jorge Cham, http://www.phdcomics.com

Figure 2

Changes Are Saved Sequentially

Figure 3

Different Versions Can be Saved

Figure 4

Multiple Versions Can be Merged

Setting Up Git


Creating a Repository


Figure 1

motivatingexampleWerewolf vs dracula by b-maze / Deviant Art. Mars by European Space Agency / CC-BY-SA 3.0 IGO. Pluto / Courtesy NASA/JPL-Caltech. Mummy © Gilad Fried / The Noun Project / CC BY 3.0. Moon © Luc Viatour / https://lucnix.be / CC BY-SA 3.0.


Tracking Changes


Figure 1

The Git Staging Area

Figure 2

The Git Commit Workflow

Exploring History


Figure 1

Git Checkout

Figure 2

https://figshare.com/articles/How_Git_works_a_cartoon/1328266

Ignoring Things


Remotes in GitHub


Figure 1

Creating a Repository on GitHub (Step 1)

Figure 2

Creating a Repository on GitHub (Step 2)

Figure 3

Creating a Repository on GitHub (Step 3)

Figure 4

The Local Repository with Git Staging Area

Figure 5

Freshly-Made GitHub Repository

Figure 6

Where to Find Repository URL on GitHub

Figure 7

Changing the Repository URL on GitHub

Figure 8

GitHub Repository After First Push

Collaborating


Figure 1

Adding Collaborators on GitHub

Figure 2

After Creating Clone of Repository

Conflicts


Figure 1

The Conflicting Changes

Open Science


Licensing


Citation


Hosting


Supplemental: Using Git from RStudio


Figure 1

RStudio screenshot showing the file menu dropdown with "New Project..." selected

Figure 2

RStudio screenshot showing New Project dialog window with "Create project from existing directory" selected

Figure 3


Figure 4

RStudio window after new project is created with large arrow pointing to vertical Git menu bar.

Figure 5


Figure 6

RStudio screenshot showing the Git menu dropdown with "Commit..." selected

Figure 7


Figure 8

RStudio screenshot showing the git menu dropdown with "History" selected

Figure 9


Figure 10

RStudio screenshot showing .gitignore open in the editor pane with the files .Rproj.user, .Rhistory, .RData, and *.Rproj added to the end

Setting up a Python ProjectStructuring a ProjectAdding Pre-commit checksLicensing complianceGitHub CI: unit tests and linting


Figure 1

planetsmathMars by European Space Agency / CC-BY-SA 3.0 IGO. Pluto / Courtesy NASA/JPL-Caltech. Moon © Luc Viatour / https://lucnix.be / CC BY-SA 3.0. Spacecraft CC 0.


Collaborating - Branching and Pull RequestsForking a repositoryCreating a new branch with changesPushing a new branchAdd branch protection rules (requirements) in the base repositoryPull (Merge) RequestsKeeping up with upstream changes


Figure 1

To create a fork go on GitHub to the page of the repository you’d like to fork, e.g. https://github.com/vlad/planets.git, then click on the ‘fork’ button, close to the top roght of the windows: Fork a repository


Figure 2

A new page will let you choose the details of the fork: - the owner, you or one of your organizations - the name of the repository, by default the same as the forked repository (unless there is a conflict in your space) Fork windows


Figure 3

On GitHub, you can switch branches by using the little drop down menu: Switch branch


Figure 4

The easiest way to open a pull request is to use the URL suggested by Git, like https://github.com/wolfsman/planetsmath/pull/new/add-square-array-method at the end of the previos section. Alternatively, go back to your personal repository on GitHub and since it is the result of a fork, it will have a pull-down “Contribute” that allows to “Open pull request”: Contribute (PR) menu


Figure 5

Either way you’ll get to a window where you can review and create the pull request. The dialogue is pre-populated probably with the correct values, anyway you can use dropboxes pick the source and destination repository and branch, and a title and description (similar to the comments in the Git commits). There are quite a few options. You should generally write a description that tells you what the changes are. If you are working on a project with other people, ‘Assignees’ are people who will be implementing changes (i.e. you) and reviewers are people who will check your work for any mistakes, code that could be written more elegantly, etc. - it is very good practice to get your code reviewed before merging and a GitHub project can also require that. Finally you can compare the content and open the pull request: Contribute (PR) dialog