Git Workshop Notes

Outline.md

#Outline:

Why are we doing this? (software in teams)

Shell

What is the shell?

• a program
• for talking to the os
• a scripting language

Why use this old stuff?

• easier to script ==> easier to automate
• many industrial systems still work this way
• you will often have to log into a remote machine, and a terminal interface is what you'll get
• understanding the terminal makes a lot of powerful command line tools available

Let's look at a directory

• pwd
• ls
• ls -l (detail about visible files)
• ls -a (invisible files)
• ls -al (combining flags)
• ls <target> (directory, etc.)

Moving between directories

• ls -F
• cd <subdir>
• cd .. (. and ..)
• cd <subdir>, cd <subsubdir> vs cd <subdir>/<subsubdir>
  • absolute vs. relative paths
• cd and cd - (also ~)

Ex:

• Get the listing for your Applications directory (*nix) or Program files directory (Win)

Making and deleting directories

• mkdir <dirname>
• mkdir -p <full/path/to/dir>
• rmdir deletes a directory, but cf. rm later

Ex:

• make a directory called sandbox inside your home directory
• make subdirectories src, doc, and test
• doc should have subdirectories internal and external
• this would be a typical project setup

Copying, moving, and deleting files

• touch makes a file (ish)
• cp <source> <dest>
  • source and dest not symmetric: source is a file, dest is a folder
  • use cp -R <src> <dest> for folders
  • use cp -R <src>/ <dest> for (recursive) copying of files only
    • note the / after src! (without that, get the directory copied, not files)
• mv
• moving lots of files in subdirectories
  • tab completion
  • globbing
• rm beware, beware
• rm -r (clean out everything recursively)

Ex:

• download some files from the internet
• practice copying and moving these files to various places in your sandbox library
• e.g.: move all the jpgs in your Downloads folder to sandbox/src
• copy all the contents of src into internal
• remove a few files

---

Git:

Setup

• Do you have git installed
  • from the command line: git --version
• Cheatsheet "configure tooling"

Editor setup

• this will take time
• see Basic git config
• Atom, Sublime, TextMate
• Notepad
• Notepad++

Why version control?

Why really?

• industrial code must be reliable
  • authoritative codebase
  • continuous integration
  • automated testing
• real world code is made by teams
  • corporate: 3 - 30 people
  • open-source: >1000 people
• we need a way to coordinate lots of people writing together
  • roll back errors
  • separate beta from release
  • allow people to work independently

Why Git?

• git is widely used
• developed for the Linux kernel
• huge open source uptake
• "social" code sites: GitHub, BitBucket, etc.
  • not the same as git, but use it
• mostly, I want to teach you concepts

How does version control work?

• diffs and changesets
• DAG model
  • branches
  • merges
  • NEVER rewrite anything (just diff)
    • false, but okay as first approx
• every node is a state of the directory
• track changes, but branching is richer, more complex

Goals today:

• basic git
• basic git workflow
• git doesn't demand a specific workflow, but some are more equal than others

Let's get started

• get to a folder where you store projects
  • on my computer, it's code
• go to GitHub; find an interesting project, clone it
  • clone button to get url (right beneath color bar)

Looking around

• find the folder for the project
• git status
• git log
• git branch -l (list branches)
• git remote (list servers we can pull from)
• git tag -l
• git checkout <> (go to an old version)

Backing up

• the git model
• distributed version control
  • not like Dropbox
  • changes are not automatic, and there are failsafes
  • optimized for cases where other people depend on your work
• multiple versions of the same code on our machine
  • my version
  • alternate versions of my version
  • other people's versions
  • versions on GitHub, etc.
  • but again not automatically synced
    • we have to manually get new changes, manually send changes
• allows us to work quickly, offline
• you might want your workflow to make more assumptions, but not everyone does

Let's start our own project

• make directory
• git init
• create/open README.md
• write some things

How we make changes

• show with online tool
• what is the staging area?
• why have one?
• two stages
  • change
  • commit
  • note: in git, everything is local (only changed on our machine)
• add and commit changes
  • writing a good commit message
  • looking at the log
• add and reset
• change multiple files
• git diff
• commit shortcuts (use with caution)

Playing nice with others

• story time:
• a simple workflow: dev branches
• show branching with online tool
• git branch
• git checkout
  • by commit hash
  • by branch name
  • by tag
• status on branch tells us where we are relative to base
• make some changes (more practice)

refactoring

• git ignore
• git mv, git rm

Ex:

• share a computer
• each of you make a branch
• make some edits on your branch that are special to your branch
• each of you commit

Pulling in work

• so we all have our own branches
• how do we get them into the "blessed" version of the code
  • you have a master branch, right?
• show merge with the online tool
• git checkout master
• git merge (into current HEAD -- beware!)
• how many people had no problem
• how many people had a conflict?
• what is a merge conflict?
• fixing merge conflicts
  • open editor
  • >>>>>
• committing fixes

Working with remotes

• typically, we work with repos that are hosted
• GitHub, etc., but may be a corporate system
• you can do p2p, but may be confusing
• most git workflows use a centralized server as "copy of record"
• show example of syncing with remote
• setting up a remote
  • (I need to have a test repo set up)
    • modify during student exercises after they clone
  • git remote add
  • git fetch
  • now your master is behind origin master
  • git merge origin/master
    • note syntax

making contributions

• github accounts
• push access
• rebase
• pull request

Resources

• Hadley Wickham on Rstudio's git integration