README.Rmd

---
title: "Bayesian linear regression"
author: "Your Name"
date: "`r Sys.Date()`"
output:
  md_document:
    variant: markdown_github
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```

## Bayesian linear regresssion

This is a skeleton package you can use as the starting point for building your Bayesian linear regression package. You should *fork* the repository to make your own version and then later use *pull requests* to hand in your project exercises and the final package.

The rest of this README file contains documentation for using this repository as a package template and for how you should hand in exercises. You shouldn't keep this text -- you can always find it again in the original repository -- but once you have read it you should update it and use this file for the documentation of your own package. When you update the documentation you should delete the `figures` directory. It just contains figures for this documentation.

### Forking a repository

Unlike the exercises repositories you have used so far, that are isolated from the template they were based upon, this repository is tied up to an original repository. This one.

With the exercises you had your very own repository and there were never any intent to update your version based on mine, or of merging your changes with my code. This is not the typical pattern used when working with source code in a git setting. There the idea is more that we have a network of versions of the code and we can merge code from one version to another.

The typical pattern is that there is a main repository, which in this case would be this repository, and then forks of that. The forks are really just other repositories, but ones you can use to push your changes to. You create a forked repository by clicking on the **fork** button at the top of the repository web page.

![Fork button](figures/fork.png)

This creates a new repository that lives at your own GitHub account. Your repository and mine live separate lives. You can push changes to your own version and they won't be pushed to mine, and changes I make to this repository will not automatically be merged into your repository.

You *can* pull any changes I make to this repository into your own version -- something I don't plan to have happen in this class -- but you cannot push your changes into my version. You don't have write permission to make changes to my code, after all.

The typical pattern is instead to request from a repository maintainer that he or she pulls changes into the main repository from your fork. I won't do that either in this class, but we will use such pull requests as the way to hand in project exercises.

### Making pull requests



### Continuous integration (CI)

I have set up this package to use features of GitHub called *continuous integration*, which essentially means that whenever you push changes to the GitHub repository, GitHub will run a number of consistency checks. How to use this is beyond the scope of this class, so I will not explain it in detail. The consequence for you is that whenever you make a pull request GitHub will check the quality of your code. This will take a while since it first has to build a clean R installation, then install all the R packages your package relies on, and then run your unit tests and check your package. After that, though, the pull request will be extended with the result of these tests.