Big concepts in Git, what I might explain to a non-technical crowd in an hour...

GitInAnHour.md

Why We Use Git

• In the past, we kept files on disk and maybe backed them up. It might be impossible to recover anything useful ever.
• Then we started using Dropbox. This was nice because each file got a linear history. Better.
• With Git, you get a snapshot taken of your project whenever you want, as much as you want.
• You can also use branches for multiple timelines, which lets you write better code because you are safer.
• Git also provides features and integrations designed to make your life easier if you work with this stuff all day long.
• We want to keep as much stuff as possible checked in when working on a project, including style guides, documentation, requirements, non-massive file assets, etc.

Git Principles

• It's all points and lines!
  • Git stores “commits,” not files per se
    • Git has no concept of an individual file outside the context of a commit
    • Note: this means you should avoid renaming files if possible!
    • When you look at a commit, you see changes in green/red
  • Every commit, except the first, has one or more parents
    • We call it a DAG and you can think of it as a “tree”
  • Every commit is uniquely identified by a SHA1 string
    • They are completely and totally unique
• Working Directory vs Git Repository
  • What you see in your working directory is not actually the git repository
    • Git is hiding in the .git folder
  • You have to tell git you want to add your changes
    • You have to tell Git you want to record a change to a file in the next commit
    • You have to tell Git you want to add or delete a file
    • You have to describe the changes in a commit message
  • (This involves both “staging” the changes, then actually making a commit)
  • (For now, ignore the staging step, you’ll just commit)
• Branches rule
  • A branch is just a name pointing to a commit’s SHA1 string
  • Branches often have a “common ancestor” which is one commit with more than one child
  • Most of our projects will have a master and a develop branch (at least)
  • We often use lots of branches, one for each feature or bug
  • This is a good thing
  • The special “branch” called HEAD is just a pointer to where you are
• Remotes
  • GitHub and BitBucket are “remotes”
    • Meaning they may have all or some of the same branches, but we use different names
    • For example, the “master” branch on github will look like origin/master
    • (Other developers could in theory also be in SourceTree there under other names!)
  • Pushing
    • When you “push,” you are telling the remote server to do two things (most of the time)
    • First, add one or more commits
    • Second, move the current branch pointer to the last one of those

Practical Git

• Using SourceTree
  • Viewing the commit list
  • General options
    • Be sure to set up your name and email address
    • Set /Users/yourname/Sites to your Project folder
  • Git options
    • Set “push branches” to current
  • In Commit view
    • Click context menu above left pane, and choose “no staging”
• Workflow
  • First, add the “ssh code” for the repo as a “bookmark” in SourceTree, which sets it up as your “remote”
  • Keep all your repositories under ~/Sites
  • Before working, make sure you’ve pulled from the server
  • If you’re feeling daring, use a branch
  • When you finish, push it back to the server
  • If you get a “merge conflict,” talk to us
• Good habits
  • How to write a good commit message
    • No longer than 50 characters
    • don't punctuate like a sentence
    • After a blank line, leave a link that might be relevant
    • Then, if appropriate, describe what you changed
  • Remembering to pull/push at the right times
  • Work on the right branch!