Entries tagged with “Git”
- All (14)
- Entries (3)
- Links (11)
- Photos (0)
Using Git Branches as Patches
At Viddler, we’re now using Git for projects, and it’s going really well so far. While we haven’t figured out the perfect workflow just yet, we’re doing some things I really like, and one of them is treating branches like patches.
Often, people think of Git branches as a full copy of the parent branch, but it’s better to treat them as a simple collection of new commits, to be applied to the parent branch later. This might not seem too revolutionary, but this small change in thinking can really improve your workflow.
For example, at Viddler we use Trac to manage tickets, and in Git. For each ticket in Trac, we create a branch, called something like 3241-fix-embed-codes. We have two permanent branches: dev, which reflects current development, and master, which is considered always production-ready. So, dev and master are going to have different code to reflect their reflective stability. To get started with a fix, we first create a feature branch from master:
git checkout -b 3241-fix-embed-codes master
This simply creates a new branch of master called 3241-fix-embed-codes and checks it out. When the ticket is completed and the code has been committed, the patch thinking really comes into play. Since this now needs to be tested in the dev environment, the branch first gets applied to the dev branch:
git checkout dev
git merge —no-ff 3241-fix-embed-codes
Using the —no-ff option on git merge is important for this patch mindset: it creates a separate commit for the merge itself, which allows you to git revert the entire thing (if necessary), rather than having to undo each individual commit within it.
Once we’ve decided this fix is read for production, it’s time to move the code over to master. Without the patch mindset, you might consider merging dev into master, but that means you’d be copying anything that’s applied to dev, some of which might not yet be ready. When you think of your feature branch as a patch, however, it’s easy to only apply the one you need. To apply this patch to master, just use a similar method as before:
git checkout master
git merge --no-ff 3241-fix-embed-codes
Now you’ve only moved the safe commits over, leaving any buggy code safely in dev.
This method may seem obvious, but the mindset has really changed the way I use Git, and I think it makes it a much more powerful tool, especially when you’re working across multiple environments (like production and staging). I’ve skipped over some additional considerations, like merging master/dev into your feature branch, but those are topics for a future post.
The Perfect Git Workflow for a One Person Project
A few months ago, I started investigating Git, and I fell in love with how much easier it made managing my code. I’m managing the source code to this site with Git, and along the way I’ve come up with a pretty good workflow for myself. The basic steps are:
- Branch
- Commit
- Rebase
- Merge
- Deploy
Let’s go through each one to see how it all works together.
Branch
With SVN, I found myself hating branching–it was always a complicated procedure, and I could never remember how to do it. In Git it’s as easy as git checkout -b <branch-name>, and you’re ready to go. Once you have a branch, you can modify it however you want, and you don’t have to worry about interfering with the master branch. In order to keep your master branch bug free, commit only to branches, not to master itself.
In addition to creating new branches for major features, I always have a few branches around that I pop into for certain things:
- “design” - any changes I want to make to the design go here
- “optimize” - optimizations to the site
- “bugfixes” - a place to work on minor bugfixes
Having these branches allows me to make small fixes to the site, and if it turns out it’s more than just a small fix, it doesn’t interfere with anything else.
Commit
In the Subversion world, it’s a pretty common practice to make very large commits, consisting of many changes. With Git, you should constantly be committing. By making many commits, you make it easier to find bugs you may have introduced, and it makes it a lot easier to track your progress. If you don’t like the thought of wading through long lists of commits in your logs, don’t worry–before bringing it over to the master branch, you can consolidate things with interactive rebasing, but while you’re hacking away on a branch, it really is advantageous to have many small commits.
Rebase
Rebasing is one of the harder things to grasp when you’re first learning about Git. For in-depth coverage of the topic, check out the Rebasing page in the Git Community Book. In a nutshell, doing git rebase master takes any commits to master and inserts them into your current branch, so you can then make sure your new code still works, and it’s a lot less hazardous than doing a merge. Rebasing your branch before putting into master is really important because it allows you to deal with any merge issues before the code goes to your main branch. To rebase, just run git rebase master.
Merge
After rebasing the branch, it’s safe to merge it into master. Since I’ve already dealt with any merge issues with the previous step, it’s as simple as checking out the master branch and running git merge <branch-name>
Deploy
I use Capistrano to deploy my code, so I’m constantly typing git push followed by cap deploy to deploy changes to my server. To make it easier, I just put both commands into one git alias:
deploy = !git push && cap deploy
Now I just need to run git deploy and it automatically pushes all of my changes to the remote Git repository and then deploys the site using Capistrano. Here’s some more information about Git aliases.
Useful tools
Though I primarily use Git through the command line, I really like using GitX to visualize branches. To host my repositories on my server, I use Gitosis, though if I had a few more projects, I’d dole out the money for a paid account at GitHub.
Have a great Git workflow? Think mine’s terrible? Let me know in the comments!
Why I won't be buying Versions
Today, Versions, a Subversion app for OS X, moved to version 1.0, marking the end of its free beta period. While many people will be shelling out the €39 (~$49) for a license, I won’t be doing the same. Having used Versions for a couple months now, it just isn’t for me.
I don’t need a fancy UI.
When I loaded Versions for the first time, I was impressed by the amount of work that went into the UI. It looked nice, and it worked pretty well too. However, I found myself working harder to accomplish simple tasks than when I used the command line. For me, it’s a lot easier to cd to the directory in the Terminal and do a svn stat rather than take the time to load up Versions and do a similar command. Even though it might be nicer to look at, Versions was just never quite as quick or intuitive as the terminal commands I had grown used to. In addition, I almost always have the Terminal open, as I’m constantly running commands during development. Having to open up another app just got in the way of my workflow.
I already use TextMate.
TextMate is the center of my coding world. It is quite simply the greatest text editor I have ever used, and it’s where I spend the vast majority of my time when I’m coding. Built into TextMate is a great SVN plugin that really makes Versions unnecessary. Without changing applications, I just hit CTRL+SHIFT+A and I’m greeted with a list of SVN commands. I tap 5, and I see a dialog where I can set my SVN commit message and choose exactly which items I want to commit from a list of changed files. Why would I need anything more sophisticated than that? If I wanted to go ahead and commit a few files with Versions, I’d have to fire up the application, locate the files I want, and hit commit. The worst part is, at least in the beta version I used, there’s no good way to select multiple files in Versions without resorting to holding the command key and clicking each file. In TextMate, it’s as simple as checking boxes.
Git is the future.
My biggest problem with spending close to $50 on a Subversion app is that I really don’t want to use SVN any more. I’ve fallen in love with Git, a distributed version control system that puts Subversion to shame. Just about every new personal project I start will be using Git, so there’s really no point in buying a program just to manage my older projects. If Versions supported Git as well, I’d definitely be considering adding it to my arsenal.
A Grain of Salt
Now, just because Versions hasn’t worked its way into my routine doesn’t mean it can’t be part of yours. I personally know several people that really enjoy Versions, and it has really improved their workflow. It’s definitely a well-made product, it just doesn’t work for me.
Also, if you’re in the market for an OS X client for SVN, definitely check out Cornerstone as well. While I haven’t used it personally, I’ve heard good things about it.