git in gear: how to track changes, travel back in time, and code nicely with others
DESCRIPTION
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!TRANSCRIPT
Git in gear: How to track changes, travel back in time,
and code nicely with others.
Fureigh @fureigh — [email protected]
NYC Camp April 10, 2014
Who am I?
Fureigh Drupal and CiviCRM developer 2014 Code for America Fellow
[email protected] — fureigh on drupal.org, IRC, Twitter, etc.
Who am I?
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?
• 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
What is version control?
(save points for your work.) !
(not only for code.)
Why use version control?(tl;dr: to reduce suffering.)
Why Git in particular?
• Cheap local branching • Multiple workflows • Fast
Let’s try it out!
• 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
Introduce yourself to Git
• Tell it your name: git config --global user.name “Your Name”
• And your email address: git config --global user.email
• And avoid unnecessary hassle: git config --global core.safecrlf true
• 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
• 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
• 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!
• 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
• 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
• 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…
• Your .gitignore file keeps Git from getting cluttered.
• Create it in the root directory of your Git repository.
Keep the crud out
• 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
• 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
• 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.
• 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
• Delete the ‘snazzytheme’ branch: git branch -d snazzytheme
• You can verify that: git branch
Deleting branches
• 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
But wait! Something’s gone wrong!
!(let’s say)
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
• 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
• 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
• (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
http://nakedstartup.com/2010/04/simple-daily-git-workflow/
• 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
• git log —name-only
• git add -p !
• git merge --squash
• (fun with git config: color diffing and more)
Gittin’ fancy
• 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
• nyccamp.org/sprint-mentor-sign-up
Thanks! Now come help at Sunday’s sprint!