Day 2

Day 2:

  1. Using git and GitHub (setup instructions)
  2. Creating a research compendium

Does git sound familiar to you?

😯 I don’t have a clue

πŸ‘ I’ve heard of it

πŸ‘ I’ve used it

❀️ I use it all the time

Choose an emoji from Reactions

/home/pao/Documents/thesis
β”œβ”€β”€ abstract.R
β”œβ”€β”€ thesis.Rmd
β”œβ”€β”€ thesis_reviwed.Rmd
β”œβ”€β”€ thesis_reviwed2.Rmd
β”œβ”€β”€ thesis_final.Rmd
β”œβ”€β”€ thesis_finalfinal.Rmd
β”œβ”€β”€ this_is_it.Rmd
β”œβ”€β”€ now_this_is_it_for_real_this_time_i_swear.Rmd
└── FINAL.Rmd
The figure shows the states of a file: untracked or tracked. When it is tracked by the repository, the file can be staged, committed or modified. With the add action the file is 'staged', with the commit action the file is 'saved' to the repository. This cycles repeats teach time the file is modified.
Concept model of a workflow using RStudio projects and git. Files are added to the staging area, and then commited to the local repository. You can push commits to the remote repository and pull new commits to your computer.

Branches: main

Branches

Scenario 1

Concept model of the workflow in scenario 1. The remote repository is copied into a local repository with a 'clone'. Files inside the local repository and the remote repository are synced with push and pull. The owned remote repository can be merged into the foreign remote repository with a pull request.

Scenario 2

Concept model of the workflow in scenario 2. A foreign remote repository can be forked to an owned remote repository with a 'fork'. The remote repository is copied into a local repository with a 'clone'. Files inside the local repository and the remote repository are synced with push and pull. The owned remote repository can be merged into the foreign remote repository with a pull request.

Research compendia

  • Folder structure
  • Specific files that document the project
  • Code and analysis structure
  • Code documentation
  • Working environment
  • And more

This is what we usually use

research_project/
β”œβ”€β”€ .gitignore
β”‚
β”œβ”€β”€ analysis
|   β”œβ”€β”€ paper.qmd       # this is the main document to edit
|   β”œβ”€β”€ references.bib  # this contains the reference list information
β”‚   └── paper_figures   # location of the figures produced by the paper
β”‚     └── 01_plot.png
β”‚
β”œβ”€β”€ data/
β”‚   β”œβ”€β”€ raw/            # data obtained from elsewhere
β”‚   └── derived/        # data generated during the analysis
|
β”œβ”€β”€ LICENSE
β”œβ”€β”€ R
β”‚   └── add_numbers.R   # R functions 
└── README.md

Document your project

  • Readme files. Use a README.md file to explain what your project is, and how to use it.

  • License. The license tells people how they can use the content of your repo. Examples are the MIT Licence or Apache. Some extra resources:

  • Contributing guide. A file called CONTRIBUTING.md and guidelines for contributors so they know what they should do if they want to help you out.

  • Code of Conduct. Good projects have code of conduct to make sure that people are treated well.

Preparations for day 3:

  1. Portable file paths with here
    • Install the here package.
  2. Managing R dependencies with renv
    • Make sure you have the renv package installed.
  3. Sharing your data