diff --git a/_freeze/schedule/slides/git/execute-results/html.json b/_freeze/schedule/slides/git/execute-results/html.json index 82571e1..c87ead9 100644 --- a/_freeze/schedule/slides/git/execute-results/html.json +++ b/_freeze/schedule/slides/git/execute-results/html.json @@ -1,7 +1,7 @@ { - "hash": "da253e0b452e7ef9a98875683757836c", + "hash": "64570f6be76429882d7d4cdf9c864b9d", "result": { - "markdown": "---\nlecture: \"Version control\"\nformat: revealjs\nmetadata-files: \n - _metadata.yml\n---\n---\n---\n\n## {{< meta lecture >}} {.large background-image=\"img/consult.jpeg\" background-opacity=\"0.3\"}\n\n[Stat 550]{.secondary}\n\n[{{< meta author >}}]{.secondary}\n\nLast modified -- 09 January 2024\n\n\n\n$$\n\\DeclareMathOperator*{\\argmin}{argmin}\n\\DeclareMathOperator*{\\argmax}{argmax}\n\\DeclareMathOperator*{\\minimize}{minimize}\n\\DeclareMathOperator*{\\maximize}{maximize}\n\\DeclareMathOperator*{\\find}{find}\n\\DeclareMathOperator{\\st}{subject\\,\\,to}\n\\newcommand{\\E}{E}\n\\newcommand{\\Expect}[1]{\\E\\left[ #1 \\right]}\n\\newcommand{\\Var}[1]{\\mathrm{Var}\\left[ #1 \\right]}\n\\newcommand{\\Cov}[2]{\\mathrm{Cov}\\left[#1,\\ #2\\right]}\n\\newcommand{\\given}{\\mid}\n\\newcommand{\\X}{\\mathbf{X}}\n\\newcommand{\\x}{\\mathbf{x}}\n\\newcommand{\\y}{\\mathbf{y}}\n\\newcommand{\\P}{\\mathcal{P}}\n\\newcommand{\\R}{\\mathbb{R}}\n\\newcommand{\\norm}[1]{\\left\\lVert #1 \\right\\rVert}\n\\newcommand{\\snorm}[1]{\\lVert #1 \\rVert}\n\\newcommand{\\tr}[1]{\\mbox{tr}(#1)}\n\\newcommand{\\U}{\\mathbf{U}}\n\\newcommand{\\D}{\\mathbf{D}}\n\\newcommand{\\V}{\\mathbf{V}}\n$$\n\n\n\n\n\n## Why version control?\n\n\n\n![](http://www.phdcomics.com/comics/archive/phd101212s.gif){fig-align=\"center\" height=\"60%\"}\n\n\n* Much of this lecture is borrowed/stolen from Colin Rundel and Karl Broman\n\n\n## Why version control?\n\n* Simple formal system for tracking all changes to a project\n* Time machine for your projects\n + Track blame and/or praise\n + Remove the fear of breaking things\n* Learning curve is steep, but when you need it you [REALLY]{.secondary} need it\n\n::: {.callout-tip icon=false}\n## Words of wisdom\n\nYour closest collaborator is you six months ago, but you don’t reply to emails.\n\n-- _Paul Wilson_\n:::\n\n\n## Why Git\n\n:::: {.columns}\n::: {.column width=\"60%\"}\n* You could use something like Box or Dropbox\n* These are poor-man's version control\n* Git is much more appropriate\n* It works with large groups\n* It's very fast\n* It's much better at fixing mistakes\n* Tech companies use it (so it's in your interest to have some experience)\n:::\n\n::: {.column width=\"40%\"}\n![](https://imgs.xkcd.com/comics/git.png){fig-align=\"center\"}\n:::\n::::\n\n. . .\n\n::: {.callout-important}\nThis will hurt, but what doesn't kill you, makes you stronger.\n:::\n\n## Overview\n\n* `git` is a command line program that lives on your machine\n* If you want to track changes in a directory, you type `git init`\n* This creates a (hidden) directory called `.git`\n* The `.git` directory contains a history of all changes made to \"versioned\" files\n* This top directory is referred to as a \"repository\" or \"repo\"\n* is a service that hosts a repo remotely and has other features: issues, project boards, pull requests, renders `.ipynb` & `.md`\n* Some IDEs (pycharm, RStudio, VScode) have built in `git`\n* `git`/GitHub is broad and complicated. Here, just what you [need]{.secondary}\n\n## Aside on \"Built-in\" & \"Command line\"\n\n:::{.callout-tip}\nFirst things first, RStudio and the Terminal\n:::\n\n\n* Command line is the \"old\" type of computing. You type commands at a prompt and the computer \"does stuff\". \n\n* You may not have seen where this is. RStudio has one built in called \"Terminal\"\n\n* The Mac System version is also called \"Terminal\". If you have a Linux machine, this should all be familiar.\n\n* Windows is not great at this.\n\n* To get the most out of Git, you have to use the command line.\n\n\n## Typical workflow\n\n\n1. Download a repo from Github\n```{{bash}}\ngit clone https://github.com/stat550-2021/lecture-slides.git\n```\n2. Create a **branch**\n```{{bash}}\ngit branch \n```\n3. Make changes to your files.\n4. Add your changes to be tracked (\"stage\" them)\n```{{bash}}\ngit add \n```\n5. Commit your changes\n```{{bash}}\ngit commit -m \"Some explanatory message\"\n```\n\n**Repeat 3--5 as needed. Once you're satisfied**\n\n* Push to Github\n```{{bash}}\ngit push\ngit push -u origin \n```\n\n---\n\n![](gfx/git-clone.png){fig-align=\"center\"}\n\n\n## What should be tracked?\n\n
\n\n#### Definitely\ncode, markdown documentation, tex files, bash scripts/makefiles, ...\n\n
\n\n#### Possibly\nlogs, jupyter notebooks, images (that won’t change), ...\n\n
\n\n#### Questionable\nprocessed data, static pdfs, ...\n\n
\n\n#### Definitely not\nfull data, continually updated pdfs, other things compiled from source code, ...\n\n## What things to track\n\n* You decide what is \"versioned\". \n\n* A file called `.gitignore` tells `git` files or types to never track\n\n```{{bash}}\n# History files\n.Rhistory\n.Rapp.history\n\n# Session Data files\n.RData\n\n# User-specific files\n.Ruserdata\n\n# Compiled junk\n*.o\n*.so\n*.DS_Store\n```\n\n* Shortcut to track everything (use carefully):\n\n```{{bash}}\ngit add .\n```\n\n## Rules\n\n* Each team has their own repo\n* Make a PR against `main` to submit\n* Peer evaluations are done via PR review (also send to Estella)\n* YOU must make at [least 5 commits]{.secondary} (fewer will lead to deductions)\n* I review your work and merge the PR\n\nProject submissions are done similarly.\n\n## What's a PR?\n\n* This exists on Github (not git)\n* Demonstration\n\n\n::: {.r-stack}\n![](gfx/pr1.png){.fragment height=\"50%\"}\n\n![](gfx/pr2.png){.fragment height=\"50%\"}\n:::\n\n## Some things to be aware of\n\n* `master` vs `main`\n* If you think you did something wrong, stop and ask for help\n* There are guardrails in place. But those won't stop a bulldozer.\n* The hardest part is the initial setup. Then, this should all be rinse-and-repeat.\n* This book is great: [Happy Git with R](https://happygitwithr.com)\n 1. See Chapter 6 if you have install problems.\n 1. See Chapter 10 for credential caching (avoid typing a password all the time)\n 1. See Chapter 13 if RStudio can't find `git`\n \n## The `main/develop/branch` workflow\n\n* When working on your own\n 1. Don't NEED branches (but you should use them, really)\n 1. I make a branch if I want to try a modification without breaking what I have.\n \n \n* When working on a large team with production grade software\n 1. `main` is protected, released version of software (maybe renamed to `release`)\n 1. `develop` contains things not yet on `main`, but thoroughly tested\n 1. On a schedule (once a week, once a month) `develop` gets merged to `main`\n 1. You work on a `feature` branch off `develop` to build your new feature\n 1. You do a PR against `develop`. Supervisors review your contributions\n \n. . .\n\nI and many DS/CS/Stat faculty use this workflow with my lab.\n\n## Protection\n\n* Typical for your PR to trigger tests to make sure you don't break things\n\n* Typical for team members or supervisors to review your PR for compliance\n\n::: {.callout-tip}\nI suggest you adopt the \"production\" version for your Team Assignments\n:::\n\n## Guardrails\n\n* The `.github` directory contains interactions with GitHub\n\n 1. Actions: On push / PR / other GitHub does something on their server (builds a website, runs tests on code)\n 1. PR templates: Little admonitions when you open a PR\n 1. Branch protection: prevent you from doing stuff\n \n* In this course, I protect `main` so that you can't push there\n\n::: {.callout-warning}\nIf you try to push to `main`, it will give an error like\n```{{bash}}\nremote: error: GH006: Protected branch update failed for refs/heads/main.\n```\n\nThe fix is: make a new branch, then push that.\n:::\n\n---\n\n* I also use a PR template. It gives you some instructions that you should follow\n\n\n::: {.callout-important}\nRead the PR template!!\n:::\n\n## Operations in Rstudio \n\n:::: {.columns}\n::: {.column width=\"50%\"}\n\n1. Stage\n1. Commit\n1. Push\n1. Pull\n1. Create a branch\n\n\n::: {.callout-note}\n## Covers:\n* Everything to do your HW / Project if you're careful\n* Plus most other things you \"want to do\"\n:::\n:::\n\n::: {.column width=\"50%\"}\n\n\n#### Command line versions (of the same)\n\n```{{bash}}\ngit add \n\ngit commit -m \"some useful message\"\n\ngit push\n\ngit pull\n\ngit checkout -b \n```\n\n:::\n::::\n\n## Other useful stuff (but command line only)\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n#### Initializing\n```{{bash}}\ngit config user.name --global \"Daniel J. McDonald\"\ngit config user.email --global \"daniel@stat.ubc.ca\"\ngit config core.editor --global nano \n# or emacs or ... (default is vim)\n```\n\n\n#### Staging\n```{{bash}}\ngit add name/of/file # stage 1 file\ngit add . # stage all\n```\n\n#### Committing\n```{{bash}}\n# stage/commit simultaneously\ngit commit -am \"message\" \n\n# open editor to write long commit message\ngit commit \n```\n\n#### Pushing\n```{{bash}}\n# If branchname doesn't exist\n# on remote, create it and push\ngit push -u origin branchname\n```\n:::\n\n::: {.column width=\"50%\"}\n#### Branching\n```{{bash}}\n# switch to branchname, error if uncommitted changes\ngit checkout branchname \n# switch to a previous commit\ngit checkout aec356\n\n# create a new branch\ngit branch newbranchname\n# create a new branch and check it out\ngit checkout -b newbranchname\n\n# merge changes in branch2 onto branch1\ngit checkout branch1\ngit merge branch2\n\n# grab a file from branch2 and put it on current\ngit checkout branch2 -- name/of/file\n\ngit branch -v # list all branches\n```\n\n#### Check the status\n```{{bash}}\ngit status\ngit remote -v # list remotes\ngit log # show recent commits, msgs\n```\n:::\n::::\n\n## Conflicts\n\n* Sometimes you merge things and \"conflicts\" happen.\n\n* Meaning that changes on one branch would overwrite changes on a different branch.\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n\n* They look like this:\n\n```\nHere are lines that are either unchanged from\nthe common ancestor, or cleanly resolved \nbecause only one side changed.\n\nBut below we have some troubles\n<<<<<<< yours:sample.txt\nConflict resolution is hard;\nlet's go shopping.\n=======\nGit makes conflict resolution easy.\n>>>>>>> theirs:sample.txt\n\nAnd here is another line that is cleanly \nresolved or unmodified.\n```\n\n:::\n\n::: {.column width=\"50%\"}\n\nYou get to decide, do you want to keep\n\n1. Your changes (above `======`)\n2. Their changes (below `======`)\n3. Both.\n4. Neither.\n\nBut always delete the `<<<<<`, `======`, and `>>>>>` lines.\n\nOnce you're satisfied, committing resolves the conflict.\n\n:::\n::::\n\n## Some other pointers\n\n* Commits have long names: `32b252c854c45d2f8dfda1076078eae8d5d7c81f`\n * If you want to use it, you need \"enough to be unique\": `32b25`\n\n* Online help uses directed graphs in ways different from statistics:\n * In stats, arrows point from cause to effect, forward in time\n * In `git` docs, it's reversed, they point to the thing on which they depend\n \n \n### Cheat sheet\n\n\n\n\n## How to undo in 3 scenarios\n\n* Suppose we're concerned about a file named `README.md`\n* Often, `git status` will give some of these as suggestions\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n### 1. Saved but not staged\n\n* In RStudio, select the file and click ``{=html} ``{=html} then select ``{=html} Revert...\n```{{bash}}\n# grab the previously committed version\ngit checkout -- README.md \n```\n\n### 2. Staged but not committed\n\n* In RStudio, uncheck the box by the file, then use the method above.\n```{{bash}}\n# unstage\ngit reset HEAD README.md\ngit checkout -- README.md\n```\n:::\n\n::: {.column width=\"50%\"}\n\n### 3. Committed\n\n* Not easy to do in RStudio...\n```{{bash}}\n# check the log to see where you made the chg, \ngit log\n# go one step before that (eg to 32b252)\n# and grab that earlier version\ngit checkout 32b252 -- README.md\n```\n\n
\n\n```{{bash}}\n# alternatively\n# if it happens to also be on another branch\ngit checkout otherbranch -- README.md\n```\n:::\n::::\n\n## Recovering from things\n\n1. Accidentally did work on main, Tried to Push but got refused\n```{{bash}}\n# make a new branch with everything, but stay on main\ngit branch newbranch\n# find out where to go to\ngit log\n# undo everything after ace2193\ngit reset --hard ace2193\ngit checkout newbranch\n```\n\n2. Made a branch, did lots of work, realized it's trash, and you want to burn it\n```{{bash}}\ngit checkout main\ngit branch -d badbranch\n```\n\n3. Anything more complicated, either post to Slack or LMGTFY\n\n\n# Practice time...\n", + "markdown": "---\nlecture: \"Version control\"\nformat: revealjs\nmetadata-files: \n - _metadata.yml\n---\n## {{< meta lecture >}} {.large background-image=\"img/consult.jpeg\" background-opacity=\"0.3\"}\n\n[Stat 550]{.secondary}\n\n[{{< meta author >}}]{.secondary}\n\nLast modified -- 01 February 2024\n\n\n\n$$\n\\DeclareMathOperator*{\\argmin}{argmin}\n\\DeclareMathOperator*{\\argmax}{argmax}\n\\DeclareMathOperator*{\\minimize}{minimize}\n\\DeclareMathOperator*{\\maximize}{maximize}\n\\DeclareMathOperator*{\\find}{find}\n\\DeclareMathOperator{\\st}{subject\\,\\,to}\n\\newcommand{\\E}{E}\n\\newcommand{\\Expect}[1]{\\E\\left[ #1 \\right]}\n\\newcommand{\\Var}[1]{\\mathrm{Var}\\left[ #1 \\right]}\n\\newcommand{\\Cov}[2]{\\mathrm{Cov}\\left[#1,\\ #2\\right]}\n\\newcommand{\\given}{\\mid}\n\\newcommand{\\X}{\\mathbf{X}}\n\\newcommand{\\x}{\\mathbf{x}}\n\\newcommand{\\y}{\\mathbf{y}}\n\\newcommand{\\P}{\\mathcal{P}}\n\\newcommand{\\R}{\\mathbb{R}}\n\\newcommand{\\norm}[1]{\\left\\lVert #1 \\right\\rVert}\n\\newcommand{\\snorm}[1]{\\lVert #1 \\rVert}\n\\newcommand{\\tr}[1]{\\mbox{tr}(#1)}\n\\newcommand{\\U}{\\mathbf{U}}\n\\newcommand{\\D}{\\mathbf{D}}\n\\newcommand{\\V}{\\mathbf{V}}\n$$\n\n\n\n\n\n## Why version control?\n\n\n![](http://www.phdcomics.com/comics/archive/phd101212s.gif){fig-align=\"center\"}\n\n\n[Much of this lecture is based on material from Colin Rundel and Karl Broman]{.smallest}\n\n\n## Why version control?\n\n* Simple formal system for tracking all changes to a project\n* Time machine for your projects\n + Track blame and/or praise\n + Remove the fear of breaking things\n* Learning curve is steep, but when you need it you [REALLY]{.secondary} need it\n\n::: {.callout-tip icon=false}\n## Words of wisdom\n\nYour closest collaborator is you six months ago, but you don’t reply to emails.\n\n-- _Paul Wilson_\n:::\n\n\n## Why Git\n\n::: flex\n::: w-60\n* You could use something like Box or Dropbox\n* These are poor-man's version control\n* Git is much more appropriate\n* It works with large groups\n* It's very fast\n* It's [much]{.secondary} better at fixing mistakes\n* Tech companies use it (so it's in your interest to have some experience)\n:::\n\n::: w-40\n![](https://imgs.xkcd.com/comics/git.png){fig-align=\"center\"}\n:::\n:::\n\n. . .\n\n::: {.callout-important appearance=\"simple\"}\nThis will hurt, but what doesn't kill you, makes you stronger.\n:::\n\n## Overview\n\n* `git` is a command line program that lives on your machine\n* If you want to track changes in a directory, you type `git init`\n* This creates a (hidden) directory called `.git`\n* The `.git` directory contains a history of all changes made to \"versioned\" files\n* This top directory is referred to as a \"repository\" or \"repo\"\n* is a service that hosts a repo remotely and has other features: issues, project boards, pull requests, renders `.ipynb` & `.md`\n* Some IDEs (pycharm, RStudio, VScode) have built in `git`\n* `git`/GitHub is broad and complicated. Here, just what you [need]{.secondary}\n\n## Aside on \"Built-in\" & \"Command line\" {background-color=\"#97D4E9\"}\n\n:::{.callout-tip}\nFirst things first, RStudio and the Terminal\n:::\n\n\n* Command line is the \"old\" type of computing. You type commands at a prompt and the computer \"does stuff\". \n\n* You may not have seen where this is. RStudio has one built in called \"Terminal\"\n\n* The Mac System version is also called \"Terminal\". If you have a Linux machine, this should all be familiar.\n\n* Windows is not great at this.\n\n* To get the most out of Git, you have to use the command line.\n\n\n## Typical workflow {.smaller}\n\n\n1. Download a repo from Github\n```{{bash}}\ngit clone https://github.com/stat550-2021/lecture-slides.git\n```\n2. Create a **branch**\n```{{bash}}\ngit branch \n```\n3. Make changes to your files.\n4. Add your changes to be tracked (\"stage\" them)\n```{{bash}}\ngit add \n```\n5. Commit your changes\n```{{bash}}\ngit commit -m \"Some explanatory message\"\n```\n\n**Repeat 3--5 as needed. Once you're satisfied**\n\n* Push to GitHub\n```{{bash}}\ngit push\ngit push -u origin \n```\n\n---\n\n![](gfx/git-clone.png){fig-align=\"center\"}\n\n\n## What should be tracked?\n\n
\n\nDefinitely\n: code, markdown documentation, tex files, bash scripts/makefiles, ...\n\n
\n\nPossibly\n: logs, jupyter notebooks, images (that won’t change), ...\n\n
\n\nQuestionable\n: processed data, static pdfs, ...\n\n
\n\nDefinitely not\n: full data, continually updated pdfs, other things compiled from source code, ...\n\n\n\n## What things to track\n\n* You decide what is \"versioned\". \n\n* A file called `.gitignore` tells `git` files or types to never track\n\n```{{bash}}\n# History files\n.Rhistory\n.Rapp.history\n\n# Session Data files\n.RData\n\n# Compiled junk\n*.o\n*.so\n*.DS_Store\n```\n\n* Shortcut to track everything (use carefully):\n\n```{{bash}}\ngit add .\n```\n\n\n## What's a PR?\n\n* This exists on GitHub (not git)\n* Demonstration\n\n\n::: {.r-stack}\n![](gfx/pr1.png){.fragment height=\"550\"}\n\n![](gfx/pr2.png){.fragment height=\"550\"}\n:::\n\n## Some things to be aware of\n\n* `master` vs `main`\n* If you think you did something wrong, stop and ask for help\n* The hardest part is the initial setup. Then, this should all be rinse-and-repeat.\n* This book is great: [Happy Git with R](https://happygitwithr.com)\n 1. See Chapter 6 if you have install problems.\n 1. See Chapter 9 for credential caching (avoid typing a password all the time)\n 1. See Chapter 13 if RStudio can't find `git`\n \n## The `main/develop/branch` workflow\n\n* When working on your own\n 1. Don't NEED branches (but you should use them, really)\n 1. I make a branch if I want to try a modification without breaking what I have.\n \n \n* When working on a large team with production grade software\n 1. `main` is protected, released version of software (maybe renamed to `release`)\n 1. `develop` contains things not yet on `main`, but thoroughly tested\n 1. On a schedule (once a week, once a month) `develop` gets merged to `main`\n 1. You work on a `feature` branch off `develop` to build your new feature\n 1. You do a PR against `develop`. Supervisors review your contributions\n \n. . .\n\nI and many DS/CS/Stat faculty use this workflow with my lab.\n\n## Protection\n\n* Typical for your PR to trigger tests to make sure you don't break things\n\n* Typical for team members or supervisors to review your PR for compliance\n\n::: {.callout-tip}\nI suggest (require?) you adopt the \"production\" version for your HW 2\n:::\n\n\n## Operations in Rstudio \n\n::: flex\n::: w-50\n\n1. Stage\n1. Commit\n1. Push\n1. Pull\n1. Create a branch\n\n\n\n[Covers:]{.secondary}\n\n* Everything to do your HW / Project if you're careful\n* Plus most other things you \"want to do\"\n\n:::\n\n::: w-50\n\n\nCommand line versions (of the same)\n\n```{{bash}}\ngit add \n\ngit commit -m \"some useful message\"\n\ngit push\n\ngit pull\n\ngit checkout -b \n```\n\n:::\n:::\n\n\n## Other useful stuff (but command line only) {.smaller}\n\n::: flex\n::: w-50\nInitializing\n```{{bash}}\ngit config user.name --global \"Daniel J. McDonald\"\ngit config user.email --global \"daniel@stat.ubc.ca\"\ngit config core.editor --global nano \n# or emacs or ... (default is vim)\n```\n\n\nStaging\n```{{bash}}\ngit add name/of/file # stage 1 file\ngit add . # stage all\n```\n\nCommitting\n```{{bash}}\n# stage/commit simultaneously\ngit commit -am \"message\" \n\n# open editor to write long commit message\ngit commit \n```\n\nPushing\n```{{bash}}\n# If branchname doesn't exist\n# on remote, create it and push\ngit push -u origin branchname\n```\n:::\n\n::: w-50\nBranching\n```{{bash}}\n# switch to branchname, error if uncommitted changes\ngit checkout branchname \n# switch to a previous commit\ngit checkout aec356\n\n# create a new branch\ngit branch newbranchname\n# create a new branch and check it out\ngit checkout -b newbranchname\n\n# merge changes in branch2 onto branch1\ngit checkout branch1\ngit merge branch2\n\n# grab a file from branch2 and put it on current\ngit checkout branch2 -- name/of/file\n\ngit branch -v # list all branches\n```\n\nCheck the status\n```{{bash}}\ngit status\ngit remote -v # list remotes\ngit log # show recent commits, msgs\n```\n:::\n:::\n\n## Commit messages {.smaller}\n\n::: {.callout-tip appearance=\"simple\"}\n1. Write meaningful messages. Not `fixed stuff` or `oops? maybe done?`\n1. These appear in the log and help you determine what you've done.\n1. Think _imperative mood_: \"add cross validation to simulation\"\n1. Best to have each commit \"do one thing\"\n:::\n\n[Conventions:]{.secondary} (see [here](https://www.conventionalcommits.org/en/v1.0.0/) for details)\n\n* feat: – a new feature is introduced with the changes\n* fix: – a bug fix has occurred\n* chore: – changes that do not relate to a fix or feature (e.g., updating dependencies)\n* refactor: – refactored code that neither fixes a bug nor adds a feature\n* docs: – updates to documentation such as a the README or other markdown files\n* style: – changes that do not affect the function of the code\n* test – including new or correcting previous tests\n* perf – performance improvements\n* ci – continuous integration related\n\n```{{bash}}\ngit commit -m \"feat: add cross validation to simulation, closes #251\"\n```\n\n## Conflicts\n\n* Sometimes you merge things and \"conflicts\" happen.\n\n* Meaning that changes on one branch would overwrite changes on a different branch.\n\n::: flex\n::: w-50\n\n[They look like this:]{.secondary}\n\n```\nHere are lines that are either unchanged\nfrom the common ancestor, or cleanly\nresolved because only one side changed.\n\nBut below we have some troubles\n<<<<<<< yours:sample.txt\nConflict resolution is hard;\nlet's go shopping.\n=======\nGit makes conflict resolution easy.\n>>>>>>> theirs:sample.txt\n\nAnd here is another line that is cleanly \nresolved or unmodified.\n```\n\n:::\n\n::: w-50\n\n[You decide what to keep]{.secondary}\n\n1. Your changes (above `======`)\n2. Their changes (below `======`)\n3. Both.\n4. Neither.\n\nAlways delete the `<<<<<`, `======`, and `>>>>>` lines.\n\nOnce you're satisfied, commit to resolve the conflict.\n\n:::\n:::\n\n## Some other pointers\n\n* Commits have long names: `32b252c854c45d2f8dfda1076078eae8d5d7c81f`\n * If you want to use it, you need \"enough to be unique\": `32b25`\n\n* Online help uses directed graphs in ways different from statistics:\n * In stats, arrows point from cause to effect, forward in time\n * In `git` docs, it's reversed, they point to the thing on which they depend\n \n \n### Cheat sheet\n\n\n\n\n## How to undo in 3 scenarios\n\n* Suppose we're concerned about a file named `README.md`\n* Often, `git status` will give some of these as suggestions\n\n::: flex\n::: w-50\n\n[1. Saved but not staged]{.secondary}\n\nIn RStudio, select the file and click ``{=html} ``{=html} then select ``{=html} Revert...\n```{{bash}}\n# grab the old committed version\ngit checkout -- README.md \n```\n\n[2. Staged but not committed]{.secondary}\n\nIn RStudio, uncheck the box by the file, then use the method above.\n```{{bash}}\n# first unstage, then same as 1\ngit reset HEAD README.md\ngit checkout -- README.md\n```\n:::\n\n::: w-50\n\n[3. Committed]{.secondary}\n\nNot easy to do in RStudio...\n```{{bash}}\n# check the log to find the chg \ngit log\n# go one step before that \n# (e.g., to commit 32b252)\n# and grab that earlier version\ngit checkout 32b252 -- README.md\n```\n\n
\n\n```{{bash}}\n# alternatively, if it happens\n# to also be on another branch\ngit checkout otherbranch -- README.md\n```\n:::\n:::\n\n## Recovering from things\n\n1. Accidentally did work on main,\n```{{bash}}\n# make a new branch with everything, but stay on main\ngit branch newbranch\n# find out where to go to\ngit log\n# undo everything after ace2193\ngit reset --hard ace2193\ngit checkout newbranch\n```\n\n2. Made a branch, did lots of work, realized it's trash, and you want to burn it\n```{{bash}}\ngit checkout main\ngit branch -d badbranch\n```\n\n3. Anything more complicated, either post to Slack or LMGTFY\n\n\n## Rules for HW 2\n\n* Each team has their own repo\n* Make a PR against `main` to submit\n* Tag me and all the assigned reviewers\n* Peer evaluations are done via PR review (also send to Estella)\n* YOU must make at [least 5 commits]{.secondary} (fewer will lead to deductions)\n* I review your work and merge the PR\n\n::: {.callout-important}\n☠️☠️ Read all the instructions in the repo! ☠️☠️\n:::\n\n\n# Practice time...\n\n[dajmcdon/sugary-beverages](https://github.com/dajmcdon/sugary-beverages)\n", "supporting": [], "filters": [ "rmarkdown/pagebreak.lua"