1. BIT 285: ( Web) Application Programming Lecture 07 : Tuesday, January 27, 2015 Git

2. Coding In A Group: Best Practices  What’s in the repository always works  Modulo bugs, of course  Do test while developing  So you’ll check in a completed feature and the tests for it  This might mean checking in a document with a checklist to manually verify  Do NOT develop the code and then go back for a 'QA' phase!!  These are required for this class! 2

3. What is version control? (and what's up with git?)  Let's look at pictures!  http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control  http://git-scm.com/book/en/v2/Getting-Started-Git-Basics#The-Three- States http://git-scm.com/book/en/v2/Getting-Started-Git-Basics#The-Three- States 3

4. Using Git  CVS  overview - single, centralized storage  Tracks source code files well (.txt files), can handle binary files (images, etc.)  Git  overview (decentralized, but can function as centralized)  Follow the tutorial  create rep  add stuff  commit  change, commit  push back to BitBucket 4

5. Starting out  Download Git from http://git-scm.com/downloadhttp://git-scm.com/download  git started out as a command-line tool, and the GUI hasn't had a good rep for a while.  Most of these instructions will be for the command line tool, but you can do the same stuff in the GUI.  To Create a local / personal repository:  Start a command prompt  cd path/to/project  git init  git add.  git status  git config --global user.email "you@example.com"  git commit –m "Checkin message here, for your teammates to know what you've done"  Alternately, you can go to a place like GitHub.com, or BitBucket.com, and create a Git project there.  Each website has it's own directions (they should all be pretty similar)  From Intro To Git For Web DesignersIntro To Git For Web Designers 5

6. Typical Individual Workflow  Work on the files  It's easy to discard you changes and roll back to the last thing that you committed  Stage the files (and add any new files)  git add –A will add new files, and get modified files ready to be added.  Commit your changes  git status will show you git's view of the world  git commit to officially update your local copy (and ONLY your local copy).  You need to include a note about what you've done (git commit –m "Fixed bug #65304" )  Now it's easy to roll back to this point  Git makes it quick & easy to do this, so think about "checking in" as more like "making a backup"  The backup has a name & is listed in git's history of your project in case you want to go back to it.  From Intro To Git For Web Designers and http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Skipping-the-Staging-AreaIntro To Git For Web Designers http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Skipping-the-Staging-Area 6

7. Exercises #1  Zeroth, install git  First, mess around with a disposable local repository  Create it  Add a file and commit it  Change the file and commit it  Figure out how to list the history 7

8. Thinking about your files  The basic Git workflow:  Modify files in the directory.  Stage the files (adds snapshots of files to git's "staging area")  Commit (take staged snapshots & store permanently)  From http://git-scm.com/book/en/v2/Getting-Started- Git-Basics#The-Three-Stateshttp://git-scm.com/book/en/v2/Getting-Started- Git-Basics#The-Three-States 8

9. Typical Workflow – GUI  You can do all this in the GUI, too, although the GUI isn't as intuitive as I'd like  The GUI focuses on managing your next commit  As opposed to showing you what's in the file system (Repository  Explore Working Copy)  More info at http://git-scm.com/book/en/v2/Git-in-Other-Environments-Graphical- Interfaceshttp://git-scm.com/book/en/v2/Git-in-Other-Environments-Graphical- Interfaces 9

10. git is ok with files that aren't part of your project 10 It's worth noting that you can tell git to ignore files "Project\Views\Someting\Index.cshtml" All.exe files Etc These will be left 'untracked', and the GUI won't show them

11. Branches  Easy, quick branches are one of git's strengths  You may (or may not) use it, but it's good to know about it.  I recommend that you not use it until you get more comfortable with git  Let's walk through http://git-scm.com/book/en/v2/Git-Branching-Branches- in-a-Nutshellhttp://git-scm.com/book/en/v2/Git-Branching-Branches- in-a-Nutshell  Visualizer to help you understand this: http://onlywei.github.io/explain-git- with-d3/#checkouthttp://onlywei.github.io/explain-git- with-d3/#checkout 11

12. Working In A Group: Centralized Workflow  Single, shared, "master" repository  Pull the most recent changes from there, push your work back to it  YOU ARE REQUIRED TO USE THIS MODEL IN THIS CLASS!  Pro Git: Distributed Workflows Pro Git: Distributed Workflows 12

13. Working In A Group: Details  Workflow: pull, { work/change, commit }, push  git pull  This will get the most 'master' version from the central repository, and integrate it into your local copy  WARNING: If you pull down the most recent copy and it's broken (doesn't compile, or doesn't run correctly) then you'll but stuck until it's fixed (or until you back the changes out – until you undo them).  This is why it's so important that the 'master copy' ALWAYS WORKS   git push  Upload your work back to the central, master copy  From Intro To Git For Web DesignersIntro To Git For Web Designers 13

14. Let's examine how this will work  Pro Git: Contributing (Small team model) Pro Git: Contributing (Small team model)  (There's an image at the end that sums this up – start there) 14

15. Exercises #2  Second, have someone on your team create a shared repository  Each person then does a git pull to pull down a copy  ADD A NEW FILE, with a unique name (maybe using your own name?)  Commit it  push your changes back to the repository  You may need to pull the most recent changes if someone pushed before your did  Modify your file, commit it, push the changes back to the repository  Third, find out what happens when you step on each other's toes   Fetch the repository (if you haven't already) to get their file, change their file locally, commit locally  Have them do the same – change their file  One at a time, push back to the repository (second pusher will need to merge changes)  Do this again, but have the other person go second 15