This document provides an introduction to using Git version control for Drupal projects. It explains what version control is, why it is useful, and compares some popular version control systems. It then focuses on Git, describing the basic Git concepts and commands for initializing a Git repository for a Drupal site, making commits locally, and pushing changes to a remote GitHub repository. The document walks through setting up SSH keys and pushing module installations from a local Drupal site to a GitHub repository as an example workflow.
Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder
Intro to Git for Drupal 7
1. Intro to Git for Drupal
Or: How I Learned To Stop Worrying and Love Version Control
2. What’s a version control
system?
• An application that allows you to record
changes to your codebase in a structured
and controlled fashion
3. Why do I need that?
• makes it way easier to undo errors / roll
back to earlier versions of code
• makes it way easier to share a code base
between developers without creating
conflicts
4. • makes it waaaaay way easier to deploy
changes from development to staging to
production environments
5. Analogy:
• Using Drupal without a version control
system is like rock climbing without any
safety gear
6. • You may be able to get away with it for
awhile, but if you slip, you’re going to die.
7. Some popular version control
systems
• CVS - Concurrent Versions System
• SVN - SubVersioN
• Git
• Mercurial
• Bazaar
• LibreSource
8. Drupal: From CVS to Git
• drupal.org used to have all module and
project code under CVS
• Drupal’s use of CVS system began January
15, 2001 with check in of Drupal 3.0.0 by
Dries Buytaert
9. • worked great for a few years
• over time CVS development stagnated
• other systems began to appear, newer and
hotter
• decision to switch from CVS to Git was
made in 2010
10. • Drupal officially switched from CVS to Git
in 2011 on February 24 at 6:08 pm EST
• excellent obituary for CVS by Larry
Garfield (Crell - http://drupal.org/user/
26398) at http://www.garfieldtech.com/
blog/cvs-obituary
• now entire Drupal project and all modules,
distributions and themes use Git
11.
12.
13.
14. So what’s Git?
• initially created in 2005 by Linus Torvalds
for Linux kernel development
• written mostly in C
• it’s a *distributed* version control system,
which means...
15. • every Git working directory contains the
complete repository and history and full
revision tracking capabilities
• you’re not dependent on a central server
and you don’t have to be online
• it’s rippingly fast - much faster than SVN,
CVS, and other systems that have a lot of
network latency
• snapshot-based
16. What’s a repository?
• it’s a directory that contains all of the data
and metadata for your Git-controlled
project
• called .git/ and it resides in your Drupal site
root directory
19. Git thee to a command line
• there are some GUI applications for Git,
but it’s essentially a command line tool
• it’s by far the most fun to use it on the
command line
20. • in the following example we’ll be using the
OS X terminal to connect to a local
Ubuntu 12.04 server running in VirtualBox
21. • we’re going to
a) install Git on the server
b) set up a new Drupal site
c) put the site into a local Git repository
(repo)
d) create a remote on GitHub
e) make a commit locally and push it to the
remote GitHub repo
26. Here we have a
fresh local
Drupal
installation.
Note that every
Drupal install
includes
a .gitignore file
27. .gitignore files tell Git what *not* to put in the
repository, i.e.: What to ignore.
The default Drupal .gitignore file contains this:
28. That tells Git to ignore all
settings.php files, all files/ directories,
and all private/ directories.
You can override and add to
the .gitignore file.
33. Now all of the
files except for
the ones
in .gitignore have
been staged -
they’re not in the
repo yet, but
they’re ready to
be put there.
How do you put
them there?
34. git commit
Actually you’ll want to type:
git commit -m “Some text describing
your commit”
35.
36. All files have now been committed to the
repository.
If we type “git status” now, we get this:
37. Now what?
• Use GitHub to make your repository
available for private or public access
38. Do I have to use GitHub?
• No, but it’s really cool and slightly easier
than setting up your own Git server
• So! - create an account if you don’t have
one (it’s free)
• login
• set up your SSH keys
39. SSH keys?
Entering your SSH keys establishes a trusted
connection between your GitHub account
and your development server(s), enabling
you to push and pull commits without having
to constantly enter your login information.
40.
41. You can see a list of your repos on your profile. Click the
indicated button to add a new one.
42.
43.
44.
45. Now all of the
files are
showing in the
github repo.
46. Dev to GitHub
• make a change on your local site and push
the change to the GitHub repo
• in this case we’re going to install five
modules - ctools, features, panels, token,
and views
47. If you check out the sites/all/modules folder in the
GitHub repo, you’ll notice it only has a README file.
48. Locally, though, we’ve used Drush to download the
five modules, which are sitting in the local copy of the
sites/all/modules folder.
We want to make those modules show up on the
GitHub repo.
49. Running “git status” shows us that the module folders
are untracked - we need to add them.
We can get all of them at once by going to sites/all/
and typing “git add modules”.
50.
51. Commit ‘em
Now we need to commit the changes. So we
type:
git commit -a -m “Added five modules -
views, panels, ctools, features, and token”
And then we push it:
git push
52. Now if we go back to GitHub and reload the page,
the modules we pushed are all there.