diff --git a/Rmd/git_presentation.Rmd b/Rmd/git_presentation.Rmd index ceb5c37..4e32c21 100644 --- a/Rmd/git_presentation.Rmd +++ b/Rmd/git_presentation.Rmd @@ -1,7 +1,7 @@ --- -title: "Git: a Primer" +title: "Git: A Primer" author: "Sean Browning" -date: "March 5th, 2021" +date: "March 18th, 2022" output: ioslides_presentation: widescreen: true @@ -27,16 +27,22 @@ opts_chunk$set(echo = FALSE) -## Quick note on jargon +## Quick Note On Today's Talk + +- This is the third version (let me know your thoughts!) +- Git is a huge topic, you may not learn everything today +- [Feel free to contribute or view online](https://github.com/beansrowning/git-talk) + +## Quick Note On Jargon Technobabble is the name of the game here, but here's a rough guide to interpret Git-speak: > - Git : "The free computer program you're about to learn about" -> - GitHub/GitLab : "Two websites (remotes) where you can store repositories" +> - GitHub : "A website (remote) where you can store repositories" > - Repo : "short for repository, a folder that is tracked with version control" -> - Remote : "A (remote) server that houses a copy of your repo" -> - Commit : "Read: take a snapshot in time, or record present state" -> - Branch / Fork : "Read: creating a parallel universe" +> - Remote : "A server that backs up your repo" +> - Commit : "Read: recording the present project state" +> - Branch : "Read: an alternate version of your project" ## Agenda @@ -44,11 +50,11 @@ Technobabble is the name of the game here, but here's a rough guide to interpret 1. Using Git locally (a crash-course in Git) 2. Using Git with all your friends (remotes and how to talk to them) -# Part 0. What is version control | and what is "Git" +# Part 0. What Is Version Control | and what is "Git" -## How many of you know the pain? +## Version Control In The Wild -```{r version-pic, out.width = "500px"} +```{r version-pic, out.width = "600px"} # TODO: New picture include_graphics("../img/insanity.png") ``` @@ -59,11 +65,11 @@ _Is this **good** version control?_ ## Motivating problems -__Why are ad-hoc approaches _often_ insufficient?__ +__Why is the standard approach _often_ insufficient?__ - Lack of standards leave collaborators confused - When things go bad, they get _really_ bad -- Project "state" is ambiguous +- Project state is ambiguous, not always linear ```{r this_is_fine, out.width = "550px"} include_graphics("../img/fine.png") @@ -73,9 +79,9 @@ include_graphics("../img/fine.png") "[git] is a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory -contents efficiently. " - Linus Torvalds +contents efficiently." - Linus Torvalds -- Conceived by Linus Torvalds in 2005 (the "Linux guy") +- Linus Torvalds in 2005
```{r git-lord-1, out.width="250px"} @@ -93,30 +99,29 @@ include_graphics("../img/dvc.png") Read Torvalds own description of it here: https://github.com/git/git/blob/e83c5163316f89bfbde7d9ab23ca2e25604af290/README
-## Okay, but what _is_ it +## Okay, But What _Is_ It Git is a tool for tracking the state of your project -- Maintain a detailed revision history -- View tracked files at any prior state -- Create separate "parallel universes" seamlessly -- Merge changes in a sensible and predictable way +- Maintain a detailed revision history of the files you want +- Create and jump between many different saved versions +- Incorporate changes in a predictable (and reversible) way
-```{r snapshot, out.width = "400px"} +```{r snapshot, out.width = "350px"} include_graphics("../img/snapshot.jpg") ```
-# How to Git it +# How To Git It -## Gitting set up | Git for Windows +## Gitting Set Up | Git for Windows - __Required regardless of what interface you use__ -- Command line daunting for the casual user -- Default commit message editor is Vim (which is _really_ daunting to the casual user) +- Mostly command line-based, also ships with lightweight GUI +- _Interface can be daunting to the casual user_
@@ -129,157 +134,135 @@ include_graphics("../img/git_for_win.png") ```
-## Gitting set up | Github Desktop +## Gitting Set Up | Github Desktop -- Serves as a "point-and-click" interface for Git operations +- Serves as a "point-and-click" interface for most Git operations - Easily manage a large number of repositories from one app -- _I will be using Github Desktop to demonstrate a GUI interface_ +- _I will be using Github Desktop for this talk_ -
+
```{r gh_desktop, out.width = "500px"} include_graphics("https://cloud.githubusercontent.com/assets/359239/26094502/a1f56d02-3a5d-11e7-8799-23c7ba5e5106.png") ``` +```{r gh, out.width = "300px"} +include_graphics("../img/github.jpg") +```
-# Part 1. Local Git commands | Let's git going +# Part 1. Using Git Locally | Let's git going -## Local Git commands +## Local Git Commands Primary objectives: - Start a new repository - Create and add files to it -- Create and merge branches -- Checkout previous revisions / other branches +- View previous revisions / other branches ```{r file-stages-1, out.width = "500px"} include_graphics("https://git-scm.com/book/en/v2/images/lifecycle.png") ``` -## Local Git commands - -I'll present each Git operation with it's command line name. - -Focus on the association of the name to its respective operation, but don't worry about memorizing them! +## Local Git Commands _(We will not be using command line here)_ -```{r hackerman, out.width = "400px"} +- The lesson here won't fully translate to command line +- Hopefully this serves as a starting place for most + +```{r hackerman, out.width = "300px"} include_graphics("../img/hackerman.png") ``` -
-It's a difficult thing, isn't it? The task is to teach Git without really going to the command line at all. +## Creating A New Repository | git init -I'd like to start by building familiarity with the concepts. From there, hopefully it becomes a bit easier to talk about things. -
+- Create a new project folder, or select and existing one +- Ideally you would create a repository at the start, but you can do so at any time +- You don't have to (and probably shouldn't) track every file -## Dataflow visualized +
-```{r git-transport-2, out.width = "500px"} -include_graphics("../img/git-transport.png") +```{r init, out.width = "400px"} +include_graphics("../img/gh_init.png") ``` -credit [Oliver Steele](https://blog.osteele.com/2008/05/my-git-workflow/) - -## Create a repository | git init - -- `git init` creates an empty repository to begin tracking your files -- Ideally you would create a repository at the start, but you can do so at any time -- Not every file present in your project folder has to be tracked in the repo +

-```{r init, out.width = "500px"} -include_graphics("../img/gh_init.png") +```{r init2, out.width = "250px"} +include_graphics("../img/init.png") ``` -## View file status | git status -`git status` displays the current state of files in your project +
+ +## View File Status | git status/add
-With Git there are four "states" that your files can reside in: +All unsaved changes to your repository will show up here + +- Add changes to commit to history +- Deselect any changes to ignore -- Untracked -- Unmodified -- Modified -- Staged +

```{r file-stages, out.width = "450px"} -include_graphics("../img/file_status.png") +include_graphics("../img/status.png") ```
-## Tracking your files | git add +## Recording Your Changes | git commit -To add a file to your repository, we use the `git add` command. +Label your changes! -- We can also use this command to stage changes of modified files -- Files added are "staged", but we haven't fully "saved" or "committed" - -```{r git-add, out.width = "450px"} -include_graphics("../img/add_before.png") -``` -```{r git-add-2, out.width = "500px"} -include_graphics("../img/add_after.png") -``` - -## Recording your changes | git commit - -`git commit` creates a record of all tracked files that you've staged. +
-Produces a message with three core parts: +- Make a succinct but useful title +- Provide more details on what changes were made -- Commit message (_"Made implicitly missing data explicit"_) -- Commit author (me) -- SHA1 hash (unique to every commit, used to reference) +

```{r commit, out.width = "500px"} -include_graphics("../img/commit.png") +include_graphics("../img/commit_gh.png") ``` -## Removing a file from the repo | git rm - -`git rm` removes a file both from disk and from the repo - -- Base operation the same as deleting file and then staging the changes -- Removes the files from the current index (and all future commits) +
-## Be mindful of what you track! +## Be Mindful Of What You Commit! ```{r deploy_key, out.width = "800px"} include_graphics("../img/deploy_key.PNG") ``` -## Be mindful of what you track! +## Be Mindful Of What You Commit! With very few exceptions, everything tracked within Git can be recovered. -- In a "parallel universe", you never deleted that data file -- Begin thinking about this *before* you make a commit +- "deleting" a file can be undone, and is still visible +- Begin thinking about this *before* you add files - Be especially careful of PII, passwords, private keys, etc. -## "ignoring" files | or: practicing mindfulness +## "Ignoring" Files | Or: Practicing Mindfulness With a `.gitignore` file in your repo, you can specify explicitly what files or folders you want to remain un-tracked. -- This is simply a file in your root folder +- This is simply a plaintext file in your root folder - [Templates](https://github.com/github/gitignore) are available online for many languages and project types ```{r ignore, out.width = "500px"} include_graphics("../img/ignore.png") ``` -# Seeing it in action +# Seeing It In Action ## Demonstration Let's see how all of these commands work for a simple task: - Initialize a new repository in GitHub Desktop -- Create and commit a simple script from RStudio +- Create and commit a simple script - Create an commit a `.gitignore` file - Remove an unwanted file from the repository @@ -287,12 +270,11 @@ Let's see how all of these commands work for a simple task: Here we will create a new repository
- ## Enter: Branching -Changes don't have to be linear! +Changes aren't always linear! -A branch allows you to diverge from the main track while keeping the state of the main track intact. +A branch allows you to work on changes to your project while keeping the "working" state intact. - A branch inherits its history from its parent - Easily merge back in changes you made in the branch (even if the parent continues to develop independently) @@ -305,7 +287,7 @@ include_graphics("../img/branch.png") -## Creating a branch | git branch +## Creating/Switching Branches | git branch `git branch` creates a new branch off of the current one @@ -316,27 +298,26 @@ include_graphics("../img/branch.png") include_graphics("../img/branches.png") ``` +## Merging Branches | git merge -## Switching branches | git checkout - -`git checkout` is used to switch between branches and a few more things: +`git merge` is used to merge a distant branch into the current one. -- The same function is used to "checkout" a previous commit -- Also used to "un-modify" a file (ie. modified -> unmodified) - - `git checkout -- ` - - **This effectively erases any unstaged progress!** +
-## Merging branches | git merge +- Incorporate the history/changes of one branch into another +- Merging does not automatically delete the branch being merged in +- Change your mind? Reverse it. -`git merge` is used to merge a distant branch into the current one. +

-- Merging does not automatically delete the branch being merged in - - The history of the distant branch is also added to the current branch -- Most of the merges locally will be "fast-forward" merges +```{r merging, out.width = "400px"} +include_graphics("../img/gh_merge.png") +``` -# Let's take a look +
+# Let's Take A Look -## Working with branches +## Working With Branches Looking back at the same repo we created earlier, let's try out these new commands: @@ -344,12 +325,7 @@ Looking back at the same repo we created earlier, let's try out these new comman - Make changes in our new branch and merge them into master - Checkout a past commit -
-If you're following along with no git installation, you might try the GitHub -visualization tool to test these concepts: http://git-school.github.io/visualizing-git/ -
- -## Where merges git dicey +## Where Merges Git Dicey If you (or your team) develops on more than one branch concurrently, you may run into merge conflicts. @@ -361,7 +337,7 @@ If you (or your team) develops on more than one branch concurrently, you may run include_graphics("../img/conflict.png") ``` -## Fixing a merge conflict +## Fixing A Merge Conflict Git will provide indicators in any files containing merge conflicts indicating what lines deviate @@ -374,56 +350,42 @@ I'm not a lawyer ``` - Fix the document as you want it to appear and stage the changes -- Sometimes it's not an A/B problem and will require revision - -Let's demonstrate... +- Sometimes it's not an A/B problem and will require revision -# Part 2. Using Git with all your friends +# Part 2. Using Git With All Your Friends -# Almost there! +# Almost There! -## Starting a new project on GitLab +## Starting A New Project On GitHub -When using GitLab or GitHub, you can start your repository directly from the website +When using GitHub, you can start your repository directly from the website - You can also create a blank repository and push a repo you've already created locally -- Projects can be housed under either a user or group namespace -- Optionally set visibility (just _how_ collaborative do you want to be?) +- Projects can be housed under either a user, group, or CDC namespace +- Optionally set visibility __Let's take a look...__ -## Interacting with remotes - -Now that we have a _remote_ repository set up, we need to introduce just three more git commands to interact with that repository: - -- git clone -- git pull -- git push - -
- -If you're reading this it's because you saw that I'm skipping fetch and died a little inside. - -I think fundamentally fetch is the safer and better option for most projects, but for small scale projects most will likely not notice the difference (especially if they're working alone). +## GitHub Namespaces -Those that do notice will discover the difference eventually, and it avoids having to teach it here in such a short time slot. +You have two main options here, depending on your project requirements: -For the astute among you who read this: +- CDCGov: Public-facing, externally visible +- CDCEnt: Private projects, no external access -git fetch pulls refs and objects from the remote, but does not merge them in. -git pull performs a fetch and then attempts to merge them - -
+```{r cdcgov, out.width = "600px"} +include_graphics("../img/cdcgov.png") +``` -## Recall our Dataflow +## Interacting With Remotes -```{r git-transport, out.width = "500px"} -include_graphics("../img/git-transport.png") -``` +Now that we have a _remote_ repository set up, we need to introduce just three more git commands to interact with that repository: -credit [Oliver Steele](https://blog.osteele.com/2008/05/my-git-workflow/) +- clone +- pull/fetch +- push -## Cloning an existing repository | git clone +## Cloning An Existing Repository | git clone `git clone` creates a local copy of a remote repository @@ -435,7 +397,7 @@ credit [Oliver Steele](https://blog.osteele.com/2008/05/my-git-workflow/) include_graphics("../img/agent_clone.jpg") ``` -## Gitting changes from remote | git pull +## Gitting Changes From Remote | git pull/fetch `git pull` returns any updates from a remote repository and merges them locally @@ -443,12 +405,13 @@ include_graphics("../img/agent_clone.jpg") - `fetch` is safer because it does not attempt to merge automatically - When in doubt, just look at the changes online -## Pushing your changes | git push +## Pushing Your Changes | git push -Finally, we send our updates to the remote repository using `git push` +Finally, we send our updates to the remote repository using `push` - Double check that everything is in order _before_ you push - It's best practice to always `pull` before `commit` and `push` +- Make sure you push your changes so everyone can access them ```{r push, out.width = "450px"} include_graphics("../img/push.jpg") @@ -484,7 +447,7 @@ include_graphics("../img/messages.jpg") -## There's a lot more here to talk about +## There's A Lot More To Talk About Stashing, blaming, diffing, cherry-picking, rebasing @@ -494,12 +457,13 @@ We will stop here for the sake of time and to avoid overload include_graphics("../img/stop.gif") ``` -## Getting help +## Getting Help I hope you'll continue to explore! - These slides (and the Rmd source) are available on [GitHub](https://github.com/beansrowning/git-talk) - Ready for a deeper dive? Check out the [book](https://git-scm.com/book/en/v2) +- Working on the command line? Try this [Katacoda course](https://www.katacoda.com/courses/git). ```{r help, out.width = "500px"} include_graphics("../img/help.gif") diff --git a/img/cdcgov.png b/img/cdcgov.png new file mode 100644 index 0000000..45f17c7 Binary files /dev/null and b/img/cdcgov.png differ diff --git a/img/clone.png b/img/clone.png new file mode 100644 index 0000000..942f9bd Binary files /dev/null and b/img/clone.png differ diff --git a/img/commit_gh.png b/img/commit_gh.png new file mode 100644 index 0000000..f0a0ba9 Binary files /dev/null and b/img/commit_gh.png differ diff --git a/img/gh_merge.png b/img/gh_merge.png new file mode 100644 index 0000000..2138d6c Binary files /dev/null and b/img/gh_merge.png differ diff --git a/img/init.png b/img/init.png new file mode 100644 index 0000000..e6e9cfa Binary files /dev/null and b/img/init.png differ diff --git a/img/insanity.png b/img/insanity.png index 4145021..db3ccfa 100644 Binary files a/img/insanity.png and b/img/insanity.png differ diff --git a/img/status.png b/img/status.png new file mode 100644 index 0000000..6987c07 Binary files /dev/null and b/img/status.png differ