Presented at NYCCamp 2014 on April 10, 2014 as a basic introduction to Git and version control. (Previous versions presented at NYCCamp 2013 and at DrupalCampNYC 10 on December 10, 2011.) Original session description: Ever made a mistake and wished for the power to turn back time? In this session you'll experience the magical world of version control, where you can try out massive code changes without worrying that you'll break your entire site, where you can have access to different versions of your code without saving tons of copies with elaborate naming schemes, and where you can collaborate with others without ever again having to utter the phrase, "Okay, I've finished working on styles.css, so you can go ahead and make your changes now." This will be a play-along crash course on Git, the version control system that Drupal.org developers (and lots of other people) use to share code with one another and save themselves time and misery. We'll start with fundamental commands, trying them out along the way. By the end of the session you'll have mastered a simple daily workflow that you'll be able to start using immediately. Plus, you'll leave with a cheat sheet and resources for future reference. This session will include: – Why use version control? – Why use Git? – How to use Git repositories on Drupal.org – Fundamental commands – A simple daily workflow – How to turn back time when something goes wrong – How to use Git to experiment safely – How to see who did what when and review changes And a bonus round, if time allows: – How to use Git on a team (or with a remote repository) that's using SVN – Additional resources/Where to learn more If you've been meaning to get around to learning Git, now's the time!

1. Git in gear:
How to track changes, travel back in time,
and code nicely with others.
Fureigh
@fureigh — info@fureigh.com
NYC Camp
April 10, 2014

2. Who am I?
Fureigh
Drupal and CiviCRM developer
2014 Code for America Fellow
info@fureigh.com — fureigh on drupal.org, IRC, Twitter, etc.
Who am I?

3. What are we going to discuss?
• What version control is and why we
care
• Setting up and getting started with
Git
• Fundamental commands
• How to use Git to experiment safely
• How to see who did what when
• Simple daily workflow (public repos)
What are we going to discuss?

4. • GitHub (github.com) – http://try.github.io
• This is by no means an exhaustive
guide to Git. See “Resources.”
• This will be less fun without a
computer, but you can still learn!
What we’re not doing

5. What is version control?
(save points for your work.)
!
(not only for code.)

6. Why use version control?
(tl;dr: to reduce
suffering.)

7. Why Git in particular?
• Cheap local branching
• Multiple workflows
• Fast

8. Let’s try it out!

9. • Linux: Search for ‘git’ or ‘git-core’
sudo yum install git / sudo apt-get install git-core
• Mac:
Download from git-scm.com
Applications -> Utilities -> Terminal
• Windows:
Download from git-scm.com
Start -> Programs -> Git -> Git Bash
Installing Git

10. 10

11. Introduce yourself to Git
• Tell it your name:
git config --global user.name “Your Name”
• And your email address:
git config --global user.email
“your@email.com”
• And avoid unnecessary hassle:
git config --global core.safecrlf true

12. • Make a new project directory:
! mkdir myproject
cd myproject
• Tell Git to start paying attention to
your project:
! git init!
• Check what you’ve done.
git status
Starting a new project

13. • Make a new file:
touch newfile.txt
• Add it:
git add newfile.txt
• And make an initial commit:
! git commit -m “Initial
commit.”
• See what you’ve done:
git log
Adding and committing

14. • The smaller your commits, the easier
it’ll be for you to go back and see
what you’ve done.
• …or undo changes that caused
damage.
Commit early and often!

15. • To edit your last commit message
(for the perfectionists among us):
git commit --amend -m “You see,
what I really meant to say was
this.”
Fear of (mis)commitment

16. • Make a change to newfile.txt.
vi newfile.txt
• See which files have been changed:
git status
• See more precisely what’s changed:
git diff
(specific file, patch creation)
Checking what’s different

17. • It’s also what we use to make
patches!
• Make another change:
vi newfile.txt
• See what’s changed:
git diff
• Make it into a patch:
git diff newfile.txt > made-
everything-more-awesome.patch
Hey, speaking of diff…

18. • Your .gitignore file keeps Git from
getting cluttered.
• Create it in the root directory of your
Git repository.
Keep the crud out

19. • Let’s make a .gitignore file.
touch secret_passwords.txt
vi .gitignore
.secret_passwords.txt
(Note: case-sensitive!)
• What else might we .gitignore?
sites/default/settings.php
*.DS_Store
• git add .gitignore
moar .gitignore

20. • Make a new branch and switch to it:
git checkout -b 41014-snazzytheme
• View current branches:
git branch
(Asterisk tells you where you are.)
• (If you wanted to switch back to master:)
git checkout master
Using Git to experiment safely

21. • Make edits.
• Check status.
• Diff to check what’s changed.
• Add files if necessary.
• Commit changes. They’ll go to the
41014-snazzytheme branch, NOT to
master.
Wash, rinse, repeat.

22. • First, switch back to master:
git checkout master
• You can verify that:
git branch
• Merge the other branch:
git merge snazzytheme
(No squashing!)
• You can see the commit in the log:
git log -1
(git log -s)
Putting it back on master

23. • Delete the ‘snazzytheme’ branch:
git branch -d snazzytheme
• You can verify that:
git branch
Deleting branches

24. • If you want to mark a commit as
special:
git tag -a v1.0 -m “Initial launch!”
• Tell me all about that, Git.
git show v1.0
Tagging

25. 25
But wait!
Something’s gone wrong!
!
(let’s say)

26. 26
photo by Amy Strycula (http://www.amystrycula.com) (Amy Strycula's personal archive)
[CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

27. • Say you delete a file:
git rm newfile.txt
• J/k! Forget everything since my last
commit!
git reset --hard
• Check that all’s well:
git status
• For individual files:
git checkout yesterday.txt
Turning back (recent) time

28. • What happened? When do you hypothesize
was last-known-good?
git log
git blame – who did this?
• First 5 characters of each long string are a
commit ID.
• To view changes between second and third
commits:
git diff 22222:33333
• To revert:
git revert HEAD <- reverts most recent
or: git checkout 22222 filename.txt
Disaster recovery

29. • (git clone)
• git checkout master
• git pull
• git checkout -b issue-branch
Creates and switches you into a branch.
• git status (as you’re going along)
• git add [filename]
• git diff
• git commit -m “Detailed commit message.”
• git checkout master
• git merge issue-branch
• git push; git branch -d issue-branch
Simple daily workflow

30. http://nakedstartup.com/2010/04/simple-daily-git-workflow/

31. • Each project (module, theme, etc.) gets its
own repository.
• Who gets commit access? Project
administrator and people to whom they grant
permission.
• If you’re a project creator, follow the steps
on the Version Control tab of your project’s
page.
• That page also lets anyone clone the git repo.
Perfect for making patches.
• drupal.org/documentation/git
Git on drupal.org

32. • git log —name-only
• git add -p
!
• git merge --squash
• (fun with git config: color diffing and more)
Gittin’ fancy

33. • git-scm.com
• Drupal-specific: drupal.org/documentation/
git
Includes GUI recommendations.
• gitready.com – great for quick answers
• gitimmersion.com – beautiful
• openhatch.org/missions/git – practice!
• try.github.com
Resources

34. • nyccamp.org/sprint-mentor-sign-up
Thanks!
Now come help at Sunday’s sprint!

35. Fureigh
fureigh.com
info@fureigh.com
@fureigh
Thanks!