<commit_before>---
layout: post
title: Version Control with git -- <NAME> and <NAME>
comments: true
category: upcoming
tags: meeting
---

If you don't have git installed:
- [Download for Windows (includes bash & git)](https://git-for-windows.github.io/)
- [Download for Mac OS X](https://git-scm.com/download/mac)
- Linux: `sudo apt-get install git`

# Git this

## What happens when you don't use version control?

### A general life example:
![](fig/phd_comics_VC.png)

You most likely started out doing something like this. Maybe you've become more sophisticated (or not) and now you

* date files
* append `_vXXX`

This is good, but you can still do better. 

## Why version control is amazing
* Code that works will be saved permanently
* If you break the code that works, reverting is easy
* You still only need to keep one version around (the VC program does the rest)
* Collaboration is kept smooth and coordinated
* Productivity is not stifled by too many people working on one document

![](fig/rock-climbing.jpg)

## Git

[Git](https://git-scm.com/) is the method of version control we're going to be working with. Other methods exist (SVN and Mercurial are the big names, and Wikipedia's [page history](https://en.wikipedia.org/w/index.php?title=List_of_version_control_software&action=history) is a more commonly known example).

Git tracks your files by essentially taking a snapshot of a directory or subdirectory structure and saving it over time. The process of capturing one of these processes is called a commit.

To be a little more specific, you can think of Git as working in three different areas or bins. There is (1) the workspace, (2) the repository, and (3) the index. 

#### Workspace: 
The set of directories and files that you actually operate on.

#### Repository (repo)
The set of linked commits corresponding to snapshots of the workspace at specified points in time.

#### Index
The staging area where you "set up your snapshot"; files in the index that have changed since your last commit will be updated on your next commit.

### Hashes
Each commit is given a unique label (called a hash) and is tied to the previous commit. This is created using a function which converts a set of information (i.e. your docs) into a string of letters and numbers. Hashes include a layer of security, since each relies on its parent's hash.

### Diagramatic Representation
Below is a diagram of the git process for a single file; I've named it file_1. You start by creating the file in your workspace. 

![](fig/git_wd01.png)

Once you are satisfied with it's progress, you decide that you want to commit your work. You add the file to the index. 

![](fig/git_index01.png)

Now you're ready. You can commit the file to your repository. (Notice that in the repository file_1 is shown with the hash of the commit. In reality the full hash for a git commit is much longer.)

![](fig/git_repo01.png)

Now, if you make some changes to file_1. Your workspace changes. 

![](fig/git_wd02.png)

You add the changed file_1 to the index.

![](fig/git_index02.png)

And again, you finally you commit. The new commit replaces the most recent commit, which moves deeper into the repository's history.

![](fig/git_repo02.png)

And the process repeats, on and on, continually building up your repository's history.

![](fig/git_repo_many.png)

## Your turn to Git started

First we want to make a directory to track as the repository for this tutorial. Go somewhere in your file system and create this directory. Then navigate inside the newly created directory. (In the following code snippets, a \$ indicates a command line prompt.)

```
$ mkdir git_tutorial
$ cd git_tutorial
```

Once you're inside, its time to initialize the repository. Intuitively, this is done with the command

```
$ git init 
```

Now, since this is likely the first time you're creating a Git repo, you may want to set up some Git configurations. Feel free to skip this step (it is optional) but if you don't do it now, Git will likely ask you for this information repeatedly in the future.

```
$ git config --global user.name "OskiBear"
$ git config --global user.email "<EMAIL>"
$ git config --global core.editor /usr/bin/nano
```
Don't worry, you can change this information later. It is stored in the hidden `.git/config` file that appears in whichever directory you ran `git init`. You can also use `git config --list` to print all of the configuration options for easy viewing.
<commit_msg>rename image paths<commit_after>---
layout: post
title: Version Control with git -- <NAME> and <NAME>
comments: true
category: upcoming
tags: meeting
---

If you don't have git installed:
- [Download for Windows (includes bash & git)](https://git-for-windows.github.io/)
- [Download for Mac OS X](https://git-scm.com/download/mac)
- Linux: `sudo apt-get install git`

# Git this

## What happens when you don't use version control?

### A general life example:
![](../images/fig/phd_comics_VC.png)

You most likely started out doing something like this. Maybe you've become more sophisticated (or not) and now you

* date files
* append `_vXXX`

This is good, but you can still do better. 

## Why version control is amazing
* Code that works will be saved permanently
* If you break the code that works, reverting is easy
* You still only need to keep one version around (the VC program does the rest)
* Collaboration is kept smooth and coordinated
* Productivity is not stifled by too many people working on one document

![](../images/fig/rock-climbing.jpg)

## Git

[Git](https://git-scm.com/) is the method of version control we're going to be working with. Other methods exist (SVN and Mercurial are the big names, and Wikipedia's [page history](https://en.wikipedia.org/w/index.php?title=List_of_version_control_software&action=history) is a more commonly known example).

Git tracks your files by essentially taking a snapshot of a directory or subdirectory structure and saving it over time. The process of capturing one of these processes is called a commit.

To be a little more specific, you can think of Git as working in three different areas or bins. There is (1) the workspace, (2) the repository, and (3) the index. 

#### Workspace: 
The set of directories and files that you actually operate on.

#### Repository (repo)
The set of linked commits corresponding to snapshots of the workspace at specified points in time.

#### Index
The staging area where you "set up your snapshot"; files in the index that have changed since your last commit will be updated on your next commit.

### Hashes
Each commit is given a unique label (called a hash) and is tied to the previous commit. This is created using a function which converts a set of information (i.e. your docs) into a string of letters and numbers. Hashes include a layer of security, since each relies on its parent's hash.

### Diagramatic Representation
Below is a diagram of the git process for a single file; I've named it file_1. You start by creating the file in your workspace. 

![](../images/fig/git_wd01.png)

Once you are satisfied with it's progress, you decide that you want to commit your work. You add the file to the index. 

![](../images/fig/git_index01.png)

Now you're ready. You can commit the file to your repository. (Notice that in the repository file_1 is shown with the hash of the commit. In reality the full hash for a git commit is much longer.)

![](../images/fig/git_repo01.png)

Now, if you make some changes to file_1. Your workspace changes. 

![](../images/fig/git_wd02.png)

You add the changed file_1 to the index.

![](../images/fig/git_index02.png)

And again, you finally you commit. The new commit replaces the most recent commit, which moves deeper into the repository's history.

![](../images/fig/git_repo02.png)

And the process repeats, on and on, continually building up your repository's history.

![](../images/fig/git_repo_many.png)

## Your turn to Git started

First we want to make a directory to track as the repository for this tutorial. Go somewhere in your file system and create this directory. Then navigate inside the newly created directory. (In the following code snippets, a \$ indicates a command line prompt.)

```
$ mkdir git_tutorial
$ cd git_tutorial
```

Once you're inside, its time to initialize the repository. Intuitively, this is done with the command

```
$ git init 
```

Now, since this is likely the first time you're creating a Git repo, you may want to set up some Git configurations. Feel free to skip this step (it is optional) but if you don't do it now, Git will likely ask you for this information repeatedly in the future.

```
$ git config --global user.name "OskiBear"
$ git config --global user.email "<EMAIL>"
$ git config --global core.editor /usr/bin/nano
```
Don't worry, you can change this information later. It is stored in the hidden `.git/config` file that appears in whichever directory you ran `git init`. You can also use `git config --list` to print all of the configuration options for easy viewing.

{'fraction_non_alphanumeric': 0.07969974610884203, 'fraction_numerical': 0.004194723479412739, 'mean_word_length': 4.098480585256049, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '104086', 'n_tokens_mistral': 2540, 'n_tokens_neox': 2380, 'n_words': 1350}