From 5fd1467fd941c8b9109a982afcfd0a22d2dc37eb Mon Sep 17 00:00:00 2001 From: will king Date: Fri, 13 Sep 2024 14:14:55 -0700 Subject: [PATCH] final version of presentation --- Lectures/slides.html | 246 +++++++++++++++++++++++++------------------ Lectures/slides.md | 123 ++++++++++++---------- 2 files changed, 211 insertions(+), 158 deletions(-) diff --git a/Lectures/slides.html b/Lectures/slides.html index d9666bb..6cb14fc 100644 --- a/Lectures/slides.html +++ b/Lectures/slides.html @@ -3,7 +3,7 @@ - + Introduction to Version Control Systems (GIT) for Economists @@ -135,7 +135,7 @@

Introduction to Version Control Systems (GIT) for Economists

-

Will King (will@youainti.com)

+

Will King (presentation+git@youainti.com)

@@ -259,11 +259,11 @@ class="sourceCode bash"> +

Get everyone to open bash at their home location. pwd, then talk +about slashes etc. Talk about spaces and quoting and escaping. Show a +variety of paths.

+

Bash Activity

@@ -275,19 +275,15 @@ zip file I’ve provided.

  • Start exploring the directories using the command line.

    • How is this similar to using your file browser?

    -
    -Viewing files -To view files from the command line, you have a couple of options: -Vi/Vim, Emacs, Nano, etc. -The most basic one you can try is Nano. -Try typing nano [filename]. -
    -
    -Instructors Notes -There are a couple of files with useful information. -Please go through them with the students as you explore the filetree. -It might be helpful to go through the directory outside of the command line too. -
    +

    Try typing nano [filename] to open one of the text +files

    +

    Getting help on the command line

    @@ -306,10 +302,14 @@ get help:

    class="sourceCode bash">    ls --help man ls info ls -
    -Instructors Notes -Examine some of the CLI options for the command presented earlier. -
    +

    Let’s Practice

    Let’s make personal wiki’s to keep track of what we are doing.

      -
    1. navigate to the base directory that I gave you.
      2. +
    2. navigate to the git_intro_download/ directory.
    3. initialize a git repo using git init wiki
    4. change directory to wiki
    5. nano basic_git_workflow.txt
      6. @@ -608,7 +608,7 @@ edits of e.txt

      This is called a conflict, where the same file has had different changes happen in different branches.

      To handle this, Git asks you to resolve it, choosing what should be -kept or removed. Resolving a conflict is called a merge.

      +kept or removed. Resolving a conflict is part of merging branches.

      Merging is the main skill we want to develop.

    git switch spellcheck
 echo "hello world" > n.txt
-git switch main
-git merge spellcheck
-git log --graph --oneline
    -

    This is called a fast-forward merge.

    +git add n.txt +git commit -m "said hello to terra" +git switch main +ls #note how n is missing +git log --oneline +git merge spellcheck +git log --oneline     +

    This is called a fast-forward merge and occurrs when branches don’t +have conflicts.

    Creating Conflicts

    @@ -709,25 +714,23 @@ same file(s).

    Let’s create a conflict in our wiki repo.

    git checkout spellcheck
-nemo favorites.txt #Talk about your favorite color
+nano favorites.txt #Talk about your favorite color
 git add favorites.txt
 git commit -m "write an actual description"
 git switch main
-nemo favorites.txt #Talk about your favorite food"
+nano favorites.txt #Talk about your favorite food"
 git add favorites.txt
 git commit -m "write an actual description"
-git log --graph --oneline
+git log --oneline
 git merge spellcheck

    Three Way Merges

    -

    In this case we have a warning message: TODO

    -

    We have two conflicting changes to the favorites.txt -file.

    -

    We need to choose between them.

    +

    In this case we have a warning message: +CONFLICT (add/add): Merge conflict in favorites.txt

    git status
-nemo favorites.txt
    +nano favorites.txt

    Note the symbols “<<<<<” “======” “>>>>>”. These tell us what the differences are between the commits

    @@ -737,6 +740,8 @@ the commits

  • stage the changes.
  • commit the merged files.
    • +
    git log --graph --oneline

    Practice (5 min)

    @@ -748,13 +753,16 @@ color. Notice that spellcheck didn’t get the changes from main.
  • merge spellcheck into main (checkout main then git merge spellcheck)
  • Resolve the merge.
    • +
  • merge main into spellcheck at some point.
    • +

    Why would normal practice be to merge your release branch into your +development branch, then merge back?

    Introducing a normal workflow

    -

    Usually, you have branches that represent “states” and branches that +

    Usually, you have branches that represent releases and branches that represent areas you are working on.

    -

    Consider the following branches

    +

    Consider the following branches.

    • main: This is the branch that you are using to present work that you consider somewhat complete, i.e. when you have a first @@ -777,7 +785,8 @@ pulling the most recent data to analyze.
    • Create data_processing branch
    • Get data_processing to a working state (committing along the way).
      • -
    • merge data_processing into main.
      • +
    • merge main into data processing, fix conflicts, +then mergedata_processing into main.
    • create a branch regression_analysis from main.
    • start writing your analysis, committing along the @@ -810,13 +819,13 @@ writing your report.

      • Sometimes when you have a bunch of small rough changes, you might want to turn them into a single (nice looking) commit.

      This is called squashing

      -
      git merge --squash [branch name]
      +
      git merge --squash [branch name]

      For example, if we had 3 commits in spellcheck, we could squash merge them into main by:

      -
      git switch main
-git merge --squash spellcheck
      +
      git switch main
+git merge --squash spellcheck

      This is one way to rewrite the DAG. It depends on the fact that branches are disposable. There is no need to keep a branch around after it is squashed.

      @@ -861,19 +870,19 @@ class="fragment">git clone /path/to/onedrive/folder/with/repo

    Remote workflow

    -
    # Begin by fetching chagnes
-git fetch remote/branch
-# Merge changes from remote branch into your current branch
-git merge remote/branch
-
-# Work like normal
-
-# Give your updates back
-git push remote/branch
    -

    There is a command that combines the fetch and merge steps:

    git pull remote/branch
    +class="sourceCode bash"># Begin by fetching chagnes +git fetch remote/branch +# Merge changes from remote branch into your current branch +git merge remote/branch + +# Work like normal + +# Give your updates back +git push remote/branch +

    There is a command that combines the fetch and merge steps:

    +
    git pull remote/branch

    Exercise

    @@ -915,8 +924,11 @@ development.

    Demo Git Forge

    I have a git forge that we are going to practice using

    -

    We are going to - add it as a remote - continue the experiment using -the remote.

    +

    We are going to

    +
      +
    • add it as a remote
      • +
    • continue the experiment using the remote.
      • +

    Cloning non-local remote

    @@ -929,74 +941,100 @@ the remote.

  • Merging to Main.
    • -

    [!NOTE] I will be removing your access to this git remote sometime -soon. You will still have a local copy of the wiki though!

    +

    NOTE!!! I will be removing your access to this git remote sometime +after the lab is over. You will still have a local copy of the wiki +though!

    -
    -

    How have I used Git in my work?

    +
    +

    Final Thoughts

    -
    -

    Tracking Code and Data

    +
    +

    How have I used Git in my work?

      -
    • I have used git to track my code for both data processing and data -analysis
      • -
    • If I were taking a class on econometrics where we have to code up +

    • I have used git to track my code for both data processing and +data analysis

      • +

    • If I were taking a class on econometrics where we have to code up some analyses, I might keep track of it in Git. A folder for each homework, tagging it right before submitting it. I would only use one -branch probably.

      • -
    • I have used git to coordinate work for an econometrics group -project.
      • -
    -
    -
    -

    Latex Development

    -
      -
    • I am currently working on my disseration in LaTeX.
      • -
    • I use git to be able to revert mistakes and sync work across -multiple computers.
      • +branch probably.

      +

    • I have used git to coordinate work for an econometrics group +project.

      • +

    • I use it to recover an analysis that I deleted by +accident.

      • +

    • I am currently working on my disseration in LaTeX.

      • +

    • I use git to be able to revert mistakes and sync work across +multiple computers.

    -
    -
    -
    -

    Final Thoughts

    -

    What should you continue learning?

      -
    • .gitignore files - Sometimes you don’t want to stage a whole class -of files. A .gitignore file tell git to not to stage them. -For example, if you are doing an analysis in python, you might get a -__pycache__/ directory. If you put a line that says -*/__pycache__/ in your .gitignore, it will not -be suggested that you stage anything in that directory.
      • -
    • Git LFS - Saving large files that are not text can be difficult, -such as when you are saving .pdf, .jpg, -.png,.xlsx, .docx, or -.zip files. Any change will cause the whole thing to be -resaved, and this can quickly add up to lots of storage being used. Git -LFS does a couple of things to reduce how much storage will be -used.
      • -
    • Branching Strategies - Knowing how to setup and use branches -properly is a powerful thing. There are tons of blogs with information -from different companies explaining how they are doing it.
      • -
    • Merging and Rebasing tools - There is so much to do here.
      • +
    • .gitignore files - Sometimes you don’t want to +stage a whole class of files. A .gitignore file tell git to +not to stage them. For example, if you are doing an analysis in python, +you might get a __pycache__/ directory. If you put a line +that says */__pycache__/ in your .gitignore, +it will not be suggested that you stage anything in that directory.
      • +
    • Git LFS - Saving large files that are not text can +be difficult, such as when you are saving .pdf, +.jpg, .png,.xlsx, +.docx, or .zip files. Any change will cause +the whole thing to be resaved, and this can quickly add up to lots of +storage being used. Git LFS does a couple of things to reduce how much +storage will be used.
      • +
    • Branching Strategies - Knowing how to setup and use +branches properly is a powerful thing. There are tons of blogs with +information from different companies explaining how they are doing +it.
      • +
    • Advanced Merging and Rebasing - There is so much to +do here.

    Most of All

    Practice!

    +
    +

    Conclusion

    +
    + + +
    +

    I’m sorry, you just became the local git expert…

    +
    +
    +

    Seriously though

    +
      +
    • Git is a useful tool to keep track of software versions and +coordinate work.
      • +
    • Most of the time you can get away with just memorizing some basic +commands and workflow
      • +
    • When things are hard, remember +
        +
      • The basic model of how it works. Try to figure out what went +wrong.
        • +
      • DuckDuckGo search is your friend. Google might be as well.
        • +
      • ChatGPT/Claude.ai are pretty good at explaining errors, commands, +etc.
        • +
      • +
    • Don’t commit anything that needs to remain secret. It is rather hard +to delete something from a Git repo.
      • +
    +

    Feedback

    • What questions do you have?
    • What would you like to keep practicing?
      • -
    • How could I improve?
      • +
    • How could I improve this presentation?
    diff --git a/Lectures/slides.md b/Lectures/slides.md index e04d538..104ed5f 100644 --- a/Lectures/slides.md +++ b/Lectures/slides.md @@ -1,6 +1,6 @@ --- title: Introduction to Version Control Systems (GIT) for Economists -author: Will King (will@youainti.com) +author: Will King (presentation+git@youainti.com) theme: league --- @@ -75,13 +75,10 @@ command "this has one argument" - `cd`: Change Directory. - `nano`: The text editor we will be using. -```{=html} -
    -Instructors Notes +::: notes Get everyone to open bash at their home location. pwd, then talk about slashes etc. Talk about spaces and quoting and escaping. Show a variety of paths. -
    -``` +::: ## Bash Activity Prep: [Download](https://www.youainti.com) and extract the zip file I've provided. @@ -93,23 +90,15 @@ Prep: [Download](https://www.youainti.com) and extract the zip file I've provide How is this similar to using your file browser? -```{=html} -
    -Viewing files -To view files from the command line, you have a couple of options: -Vi/Vim, Emacs, Nano, etc. -The most basic one you can try is Nano. -Try typing nano [filename]. -
    -``` -```{=html} -
    -Instructors Notes +Try typing `nano [filename]` to open one of the text files + +::: notes There are a couple of files with useful information. + Please go through them with the students as you explore the filetree. + It might be helpful to go through the directory outside of the command line too. -
    -``` +::: ## Getting help on the command line @@ -127,12 +116,14 @@ man ls info ls ``` -```{=html} -
    -Instructors Notes +::: notes Examine some of the CLI options for the command presented earlier. -
    -``` +Maybe: + +- `ls -l` +- `ls -a` + +::: @@ -216,7 +207,7 @@ git commit Let's make personal wiki's to keep track of what we are doing. -1. navigate to the base directory that I gave you. +1. navigate to the `git_intro_download/` directory. 2. initialize a git repo using `git init wiki` 3. change directory to wiki 4. `nano basic_git_workflow.txt` @@ -408,7 +399,7 @@ changes happen in different branches. To handle this, Git asks you to resolve it, choosing what should be kept or removed. -Resolving a conflict is called a merge. +Resolving a conflict is part of merging branches. Merging is the main skill we want to develop. @@ -503,12 +494,16 @@ Ok, let's do the following: ```bash git switch spellcheck echo "hello world" > n.txt +git add n.txt +git commit -m "said hello to terra" git switch main +ls #note how n is missing +git log --oneline git merge spellcheck -git log --graph --oneline +git log --oneline ``` -This is called a fast-forward merge. +This is called a fast-forward merge and occurrs when branches don't have conflicts. ## Creating Conflicts @@ -520,28 +515,24 @@ Let's create a conflict in our wiki repo. ```bash git checkout spellcheck -nemo favorites.txt #Talk about your favorite color +nano favorites.txt #Talk about your favorite color git add favorites.txt git commit -m "write an actual description" git switch main -nemo favorites.txt #Talk about your favorite food" +nano favorites.txt #Talk about your favorite food" git add favorites.txt git commit -m "write an actual description" -git log --graph --oneline +git log --oneline git merge spellcheck ``` ## Three Way Merges -In this case we have a warning message: `TODO` - -We have two conflicting changes to the `favorites.txt` file. - -We need to choose between them. +In this case we have a warning message: `CONFLICT (add/add): Merge conflict in favorites.txt` ```bash git status -nemo favorites.txt +nano favorites.txt ``` Note the symbols "<<<<<" "======" ">>>>>". @@ -553,6 +544,9 @@ To resolve the commit: - stage the changes. - commit the merged files. +```bash +git log --graph --oneline +``` ## Practice (5 min) @@ -561,13 +555,17 @@ To resolve the commit: Notice that spellcheck didn't get the changes from main. - merge spellcheck into main (checkout main then `git merge spellcheck`) - Resolve the merge. +- merge main into spellcheck at some point. + +Why would normal practice be to merge your release branch into your +development branch, then merge back? ## Introducing a normal workflow -Usually, you have branches that represent "states" and branches that represent +Usually, you have branches that represent releases and branches that represent areas you are working on. -Consider the following branches +Consider the following branches. - `main`: This is the branch that you are using to present work that you consider somewhat complete, i.e. when you have a first draft of your data @@ -588,7 +586,7 @@ What this might look like. >2. write things such as README in main. >3. Create `data_processing` branch >4. Get `data_processing` to a working state (committing along the way). ->5. merge `data_processing` into main. +>5. merge main into data processing, fix conflicts, then merge`data_processing` into main. >6. create a branch `regression_analysis` from main. >7. start writing your analysis, committing along the way. >8. Notice that the data is incorrect. @@ -715,6 +713,7 @@ A Git Forge provides I have a git forge that we are going to practice using We are going to + - add it as a remote - continue the experiment using the remote. @@ -727,12 +726,15 @@ We are going to - Pushing branches from CLI - Merging to Main. -> [!NOTE] -> I will be removing your access to this git remote sometime soon. You will still have a local copy of the wiki though! +> NOTE!!! +I will be removing your access to this git remote sometime after the lab is over. +You will still have a local copy of the wiki though! -# How have I used Git in my work? -## Tracking Code and Data + +# Final Thoughts + +## How have I used Git in my work? - I have used git to track my code for both data processing and data analysis - If I were taking a class on econometrics where we have to code up some @@ -740,40 +742,53 @@ analyses, I might keep track of it in Git. A folder for each homework, tagging it right before submitting it. I would only use one branch probably. - I have used git to coordinate work for an econometrics group project. - -## Latex Development +- I use it to recover an analysis that I deleted by accident. - I am currently working on my disseration in LaTeX. - I use git to be able to revert mistakes and sync work across multiple computers. -# Final Thoughts - ## What should you continue learning? -- .gitignore files - Sometimes you don't want to stage a whole class of files. +- **.gitignore files** - Sometimes you don't want to stage a whole class of files. A `.gitignore` file tell git to not to stage them. For example, if you are doing an analysis in python, you might get a `__pycache__/` directory. If you put a line that says `*/__pycache__/` in your `.gitignore`, it will not be suggested that you stage anything in that directory. -- Git LFS - Saving large files that are not text can be difficult, such as +- **Git LFS** - Saving large files that are not text can be difficult, such as when you are saving `.pdf`, `.jpg`, `.png`,`.xlsx`, `.docx`, or `.zip` files. Any change will cause the whole thing to be resaved, and this can quickly add up to lots of storage being used. Git LFS does a couple of things to reduce how much storage will be used. -- Branching Strategies - Knowing how to setup and use branches properly is a +- **Branching Strategies** - Knowing how to setup and use branches properly is a powerful thing. There are tons of blogs with information from different companies explaining how they are doing it. -- Merging and Rebasing tools - There is so much to do here. +- **Advanced Merging and Rebasing** - There is so much to do here. ## Most of All ### Practice! +## Conclusion + +![If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.](https://imgs.xkcd.com/comics/git.png) + +I'm sorry, you just became the local git expert... + +## Seriously though + +- Git is a useful tool to keep track of software versions and coordinate work. +- Most of the time you can get away with just memorizing some basic commands and workflow +- When things are hard, remember + - The basic model of how it works. Try to figure out what went wrong. + - DuckDuckGo search is your friend. Google might be as well. + - ChatGPT/Claude.ai are pretty good at explaining errors, commands, etc. +- Don't commit anything that needs to remain secret. It is rather hard to delete something from a Git repo. + ## Feedback - What questions do you have? - What would you like to keep practicing? -- How could I improve? +- How could I improve this presentation?