Cloud Platform
Effective Git Practices for Drupal Development
Possibly the nerdiest thing that's ever escaped my mind is a reimagining of the lyrics to 1983 pop hit The Safety Dance by Men Without Hats in tribute to my favorite distributed version control system, Git, contra CVS:
"We can branch if we want to. We can leave your friends behind. 'Cause your friends don't branch, and if they don't branch, well they're no friends of mine!"
You may think that's a little over the top, but even if your appreciation for Git hasn't advanced to the point of putting anachronistic praise into the mouths of Canadian synth pop bands of yore, I probably don't have to persuade you that it's pretty awesome. It's been a few years since Drupal.org made the switch to Git, and by now most folks in the community are using it if they're using anything. But not all of us have learned to use it effectively yet. My goal in this article is to provide a roadmap to help everyone get there.
Of course, if you want to be effective with anything, you have to master the fundamentals first. [Insert tired sports cliche here.] A great place to do so with Git is the official documentation. Here are the highlights, if you ask me (which, incidentally, I'm pretending you did):
git checkout -` checks out the previous branch, just like `cd -` in bash changes to the previous directory. You stand corrected.If you read the Git Book you'll learn about a number of advanced features, but a few are worth calling out here:
The whole point of version control is that you never lose a committed change. But we all make mistakes: We let a password or other sensitive information slip into an open source repository. We create an ugly tangle of commits that are hard to review or merge. Git helps you recover from such errors by rewriting history with `git commit --amend`, `git rebase` / `git rebase -i`, and family.
Rebasing in particular seems to confuse newbies, but once you learn to use it properly you'll appreciate its power. Of course, as with any power tool, you need to be careful. It's all fun and games until somebody loses an eye a commit. This is probably a good time to learn about the recovery plan.
Speaking of making mistakes, at some point you're going to commit a change that breaks your application, and you're going to want to be familiar with Git's debugging tools when that happens:
If you don't notice a regression right away, it can be hard to isolate the problem code. `git bisect` is designed precisely for figuring out where brokenness was introduced. It takes a little practice to become proficient, but if you break stuff a lot you'll get the hang of it. [wink] If your build script takes a long time or your test suite is adequately complex, you can even automate the process.
Coming from the other direction, when you've identified some code and you want to know where it came from, `git blame` is the tool for the job. Point it at a file, and it will tell you, line by line, who added the code at what time in what commit. Of course, it can be more complicated than that. For example, if the line you're interested in has been non-meaningfully changed since it was first introduced (such as by changing its indentation), it will be identified with the later, irrelevant commit. Git still has you covered. You'll just need to sophisticate your approach a little.
A brief excursus at this point to give disproportionate attention to a feature of Git that doesn't get the love it deserves: `git show-branch` is like a network graph for the command line. It shows branches in parallel up to a common ancestor. I use it all day long, but I've scarcely met anyone else that knew about it. To get a sense of what you may be missing, try a few of these out:
git show-branch`git show-branch --sha1-name`git show-branch first-branch second-branch`git show-branch */branch-name`git show-branch \*/\*`Now that we know how to use our tools, lets talk about tuning them.
git config --global color.ui auto`, because life in grayscale is for the dogs. Then, as long as you're picking low-hanging fruit, set up a global .gitignore file and banish .swp, .DS_Store, and other garbage files from your repos once and for all.lp` for `log --graph --pretty=format:'%C(yellow)%h%C(cyan)%d%Creset %s %C(white)- %an, %ar%Creset'`!)Well, we went over quite a bit here. If you followed along, you have a good understanding of Git concepts and commands and you have a well-optimized environment. If you've mastered everything discussed, there's probably a job for you at Githubor better yet, here at Acquia!
Cloud Platformgit status