Git Workshop

Boss says: I’m thinking we need the app to say the abc’s…make me a prototype

Person 2:

• git pull
• git branch abc
• git checkout abc
• touch abc.rb
• edit abc: puts 'abcdefgh' (pretend this takes you a really long time & is really hard)
  

  Boss says to Person 1: ARRRG! You made count.rb with 444, not 4! Don’t you know how to count to 10? Fix it!

Person 1:

• git checkout master
• change count.rb so that it counts correctly
• git add .
• git commit -m "fixed bug in count.rb"
• git push

Person 2

• git checkout master
• git pull
• git log
• find the sha for the commit called “fixed bug in count.rb”, copy it
• git checkout abc
• git cherry-pick master <sha you copied>

git cherry-pick is good for including a particular bug fix that was developed on a different branch into the branch you are working on.

Boss says to both Person 1 & Person 2: make me an app that displays every single number in pi.

• you make a new file: touch pi.rb
• type puts '3.141'
  

  Boss says: wait, wait…first make me an app that counts to 10

• you sigh
• you type into the command line git stash save

• you make a new file touch count.rb
• type into the new file puts '1,2,3,444,5,6,7,8,9,10' (yes, 444)
• git commit -am "count to ten finished"
• git stash apply

Use git stash if want to switch out your working set to another branch, work on something else, then switch back to your original work. A second possible git stash scenario is if you aren’t ready to commit but you need to pull (something that you and someone else are both modifying)

Boss says: I like both sentences! I want the app to say “My boss is the best boss ever!” on the first line and “Welcome to the best Ruby app ever written!” on the second line

• Person 1 goes back to master branch: git checkout master
• Person 1 merges in the best_boss branch git merge best_boss
• in this case, your merge “fast forwards” because the master branch hasn’t had any changes since the bestboss branch was created. It is simply moved forward to the latest bestboss commit because there are not any conflicts.
• Person 1 pulls the git repo: git pull (gets master, which in this case is unchanged)
• Person 1 checks out best_app git checkout best_app
• git pull origin best_app (gets the best_app branch)
• Person 1 checks out master git checkout master
• merge best app into master: git merge best_app

GIT DIFF:

• git will tell you that the merge failed. To see the difference between the two files, use: git diff
• another cool way to see the difference is gitk
• To see the difference in you application & fix the merge conflict, look at hello.rb. Both of the boastful sentences should be in the file with a bunch of extra git syntax around them. Since we want both sentences, we can delete all of the git syntax, leaving just the two sentences. In other merge conflict situations, you may want to delete one version of the code along with the git syntax.
• git commit -am "fixed merge conflict"
• git push

Boss says: One person in each pair should clone the other person’s git repo from github so that you are both working on the same repo.

• git clone git@github.com:<user name>/git_demo.git git_demo_clone

Boss says: I want one person in the pair to make the app say “My boss is the best boss ever!” The other should make it say “Welcome to the best Ruby app ever written!”

Person 1:

• git branch (shows you master branch, a branch that was auto-created by git for you)
• git branch best_boss (creates a new branch called best_boss)
• git branch (you can see the two branches you have. The ‘*’ indicates which branch you are currently on)
• git checkout best_boss (moves you to the new best_boss branch you created)
• git branch (now the ‘*’ is next to best_boss)
• type puts "My boss is the best boss ever!" into hello.rb
• git commit -am "updated hello.rb with best boss text"
• git push origin best_boss

Person 2:

• git branch (shows you master branch, a branch that was auto-created by git for you)
• git branch best_app (creates a new branch called best_app)
• git branch (you can see the two branches you have. The ‘*’ indicates which branch you are currently on)
• git checkout best_app (moves you to the new best_app branch you created)
• git branch (now the ‘*’ is next to best_app)
• type puts "Welcome to the best Ruby app ever written!" into hello.rb
• git commit -am "updated hello.rb with best app text"
• git push origin best_app

show your branches to your the boss.

Boss says: I want the app to say hello in French!

• change hello.rb so that it says puts 'bonjour!'
• type into command line:
• git add .
• git commit -m "changed greeting from English to French"

Boss says: I changed my mind! I want the app to say hello in Spanish!

• change hello.rb so that it says puts 'hola!'
• type into command line:
• git status (it shows that you’ve modified hello.rb)
• git commit -am "changed greeting from French to Spanish" (using -a does git add . for you)

Boss says: I changed my mind! I want the app to say hello in Hebrew!

• change hello.rb so that it says puts 'shalom!'
• type into command line:
• git status (make sure the modifications make sense)
• git add hello.rb
• git commit -m "changed greeting from Spanish to Hebrew"

Boss says: I changed my mind! I want the app to say hello in Esperanto!

• change hello.rb so that it says puts 'saluton!' save

Boss interrupts you: I changed my mind! I want the app to say hello in Hebrew!

• type into command line:
• git reset --hard (takes your uncommited changes back to last commit. If the problematic commit is the most recent commit, and you have not yet made that commit public, you can just destroy it using git reset.)
• git commit -am "decided not to change greeting from Hebrew to Esperanto"

Boss says: I changed my mind! I want the app to say hello in French!

• git revert HEAD^ (this takes you back to the commit before the latest commit)

A little explanation: git reset, git revert and git checkout can all be used in different situations where you want to go back to previous commits. git reset rewrites history and should only be used when you are working locally and haven’t yet pushed your changes to the central repo. git revert records a new commit to reverse the effect of an earlier commit. You can use git checkout if you want to extract specific files as they were in another commit.

If your repo gets hosed by reverting, resetting & checking out, git reflog may help to rescue you. It keeps track of everything that has happened and you can use HEAD@{number} to get back any lost info through merging, cherry-picking or more reverting, resetting & checking out.

Boss says: I want a Ruby app!!!

You type into command line:

• mkdir git_demo
• cd git_demo
• touch hello.rb
• open hello.rb and type puts 'hello' save the file
• touch goodbye.rb
• open goodbye.rb and type puts 'goodbye' save the file

Boss says: If you lose the source code, you are fired!

You type into command line:

• git init (initializes your git repository)
• git status (shows a summary of changes made to working directory – you have two untracked files)
• git add hello.rb (adds a single file, hello.rb to staging)
• git status (shows that hello.rb is now added and is ready to be commited. goodbye.rb is not ready to be committed.)
• git add . (adds all files to staging – in this case, just goodbye.rb)
• git status (shows that both hello.rb and goodbye.rb are staged for the next commit)
• git commit -m "first commit" (commits files you added to staging index to the git repo)

then you go to github, create an account, go to your dashboard, click on “New Repository”, fill out “project name” with “git_demo” and “description” with a description.

at the command line you type:

• git remote add origin git@github.com:<your user name>/git_demo.git
• git push origin master

go to your github account and admire your new repository!

Your boss is demanding.  Get ready to learn Git to keep from getting fired!

1. Git Basics
2. Git Reset & Git Revert
3. Git Branch
4. Git Merge & Git Diff
5. Git Stash
6. Git Cherry-pick

1. when to use cherry-pick
2. when to use checkout (branch & files)
3. when to use merge
4. when to use reset
5. when to use revert
6. when to use rebase
7. when to use branch vs stash
8. how to ignore files
9. find as many ways to add & commit as you can (all the options & flags, what they do)
10. how to delete files properly

Exercise

The git workshop will commence Tuesday, February 23rd 2010.  We will git learned.