• 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

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 : “A website (remote) where you can store repositories”
• Repo : “short for repository, a folder that is tracked with version control”
• Remote : “A server that backs up your repo”
• Commit : “Read: recording the present project state”
• Branch : “Read: an alternate version of your project”

1. What is version control?
2. Using Git locally (a crash-course in Git)
3. Using Git with all your friends (remotes and how to talk to them)

Is this version control?

Is this good version control?

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, not always linear

“[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

• Linus Torvalds in 2005

Git is a tool for tracking the state of your project

• 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

• Required regardless of what interface you use
• Mostly command line-based, also ships with lightweight GUI
• Interface can be daunting to the casual user

• 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 for this talk

Primary objectives:

• Start a new repository
• Create and add files to it
• View previous revisions / other branches

(We will not be using command line here)

• The lesson here won’t fully translate to command line
• Hopefully this serves as a starting place for most

• 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

Label your changes!

With very few exceptions, everything tracked within Git can be recovered.

• “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.

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 plaintext file in your root folder
• Templates are available online for many languages and project types

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
  
• Create an commit a .gitignore file
  
• Remove an unwanted file from the repository

Changes aren’t always linear!

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)

git branch creates a new branch off of the current one

• If you’re just starting out, the current branch is likely master or main
  
• Visualize it yourself

git merge is used to merge a distant branch into the current one.

Looking back at the same repo we created earlier, let’s try out these new commands:

• Create a new branch and check it out
• Make changes in our new branch and merge them into master
  
• Checkout a past commit

If you (or your team) develops on more than one branch concurrently, you may run into merge conflicts.

• If the same line is edited across branches, Git will not know what one takes precedence in a merge
• Several merge strategies exist to automate this
  
• For small merges it’s often easier to workup manually

Git will provide indicators in any files containing merge conflicts indicating what lines deviate

<<<<<<< <current_branch>
I'm not a cat
=======
I'm not a lawyer
>>>>>>> <branch_being_merged>

• 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

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, group, or CDC namespace
  
• Optionally set visibility

Let’s take a look…

You have two main options here, depending on your project requirements:

• CDCGov: Public-facing, externally visible
• CDCEnt: Private projects, no external access

Now that we have a remote repository set up, we need to introduce just three more git commands to interact with that repository:

• clone
  
• pull/fetch
• push

git clone creates a local copy of a remote repository

• You Only Clone Once (YOCO)
• By default, the directory will be named after the title of the repository
  
• It is not possible to “clone” bits and pieces of a larger repository

git pull returns any updates from a remote repository and merges them locally

• Notice that I said it merges those changes (be wary)
  
• fetch is safer because it does not attempt to merge automatically
  
• When in doubt, just look at the changes online

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

There are many workable models for how best to use these commands

My advice:

Stashing, blaming, diffing, cherry-picking, rebasing

We will stop here for the sake of time and to avoid overload

I hope you’ll continue to explore!

• These slides (and the Rmd source) are available on GitHub
  
• Ready for a deeper dive? Check out the book
• Working on the command line? Try this Katacoda course.