One thing I am personally bad at is version control. Oh, don’t get me wrong, I’m great decent at it for code at work, but I still have a tendency to cowboy code. Bad me.
Part of why is that I don’t want to have my stuff public. At the same time, I don’t want to pay Github while I’m learning, and I want a GUI. Why not overcomplicate my life! I’ll add on one more, I want a website where I can look at my changes all pretty like. Last time I did this via SVN, hated it, never used it, and walked away. This time I decided to use Git, and once I started using it via the command line, I realized how freaking awesome this was. And since I’m using CLI, I ran git config --global color.ui true to get pretty colors.
I should note that I use Coda2 by Panic and I love it. But. It doesn’t have an easy way to properly branch and tag in SVN or Git, which is something I’m used to having. And my master plan is this. Master will have the ‘live’ real code. The branches are releases. When a branch is ready to go live, I merge it with master.
So let’s get started.
Stage One: Install Git
I followed Gits official directions for installing Git on my server, so once you’ve got things like that up and running, it’ll be time for the webpage.
Cart comes after horse, though. I had a hell of a time getting my own SVN crap up and running, but git was way easier. There was far less to mess with to install, since I’d already done it before. With Git, I don’t need to mess with svnserve or daemons, since git isn’t the ‘server’ where my code is stored, it’s just another repository/clone. It breaks my head sometimes, but this is a case where it’s going to be easy. Install any Git dependencies (on CentOS that means I ran yum -y install zlib-devel openssl-devel cpio expat-devel gettext-devel ) and then install from command line:
cd /usr/local/src wget http://git-core.googlecode.com/files/git-1.8.2.2.tar.gz tar xvzf git-1.8.2.2.tar.gz rm git-1.8.2.2.tar.gz cd git-1.8.2.2 ./configure make make install
Done, and now I’m on 1.8.2.2. Upgrading is as easy as doing the wget again.
Stage Two: Make Repositories
At this point, the official git directions say you should make a git account, but after some pondering, I decided to put my repos in /home/myuser/gitrepos/ so I can easily add my repositories to my local computer. Everything is locked down via RSA keys anyway, so I can secure connect from my computers and everything is basic and simple and safe. If I want to make more repositories for other accounts, I can do it as a one-by-one basis. Right now I have no need for group stuff, this is a me repository after all. If I did, I’d use git’s directions for making a git user instead.
I made projects for my domains (ipstenu and jfo) and then one for my server (mothra). I hooked into them with Coda2, which is my app of choice, and I tested that I could get and push files. I’ll come back to this in a second.
Stage Three: Webify it!
Next up was webifying things. I want to do this, even though I’m putting it behind a password, because I’m visual and being able to see what I’ve got going on is helpful to me. I went with GitList because it looked nice. The drawback to these things is that if I used a shared repository (say /home/gituser/gitrepos/ for example) then I’d have to web-alias to the gituser instead of having it hosted as ‘Ipstenu’ … which is okay. If I was really making a full blown shared group, I’d probably buy gitstenu.org and point it there.
Awesomesauce! It works! Except for this error Unnamed repository; edit this file ‘description’ to name the repository. That’s easily fixed on the server by editing the description file.
Those initial repositories are for my non-public files, actually. That’s where I keep copies of the obscure shell scripts I run, stuff that isn’t web accessible. After I got those set up, I made repositories for my themes and my mu-plugins. This gave me folders like ipstenu-mu-plugins and jfogenesis-wp because I named the theme ‘jfogenesis’ for WordPress, MediaWiki, and ZenPhoto. Still this let me progress to …
Stage Four: Control
The whole reason I did all the rest of that was so I could do this, which seems redundant, but bear with me.
- I checked out all the code locally, edit it, and push it back up to the repos on my server
- On the webserver, I check out the code with a simple
git cloneto folder2 (trust me) - switch
folderandfolder2(you know how to move things) - Checkout the new code with a
git pull. If I want to checkout a specific version, it’sgit checkout -b mysite-REL_1.0 origin/REL_1.0(It’s worth mentioning that I made a branch for everything at the start as REL_1.0 because reasons.)
And that’s it.
Stage Five: Updates
Here’s my current process.
Locally, I start work on my new version so I make a new branch: git checkout -b REL_2.0
Edit my files and add and remove them as needed:
git rm <filename> git add .
Check them in when I’m done with the files: git commit -m "Editing foo and bar, replacing baz."
When I’m ready with it to be tested, I push it: git push origin REL_2.0
Everything tests well on the dev server(Just pretend there is one.)? Okay! Let’s merge!
git checkout master git merge REL_2.0 git push origin master
Summary
Since this is just me running stuff, it’s pretty easy to keep track of everything. Having the website makes it easy for me to see what’s I last did and what’s changed:
Again, yes, I put the git website behind password protection. I may change this later, if I determine I never put anything secret up there. But right now, this is good for me. After a couple days of using it, I liked it a lot. Enough that, unlike my foray into SVN, I kept using it. It was easy for me to keep my code organized and up to date. If I had to update ‘live’ I could still use branches easily and roll things back painlessly. That’s pretty darn cool.
Comments
6 responses to “Personal Version Control With Git”
I’m lazy. I just use Bitbucket for all my private repos.
I have an inherent distrust of someone else’s code on someone else’s server. Especially when some of the code I want to backup (wp-config files) have passwords in them.
A fair point. I always exclude config from my repos — my basic use case is “have a place that’s not on my machines to store versioned code for client xyz” rather than “use git for backups”, so the needs are a bit different.
In the best case scenario, my config files would be set and forget (heh), but in reality, I’m often tweaking things. I suppose it is a bit more ‘using git for backups’ though. It’s not like I can’t rebuild my configs while waiting on my coffee at this point. On a non-backup side of things, I have code that is private and needs to stay that way not for password reasons but for … well. Reasons, damn it. Dad’d be mighty annoyed if they weren’t.
So… you installed Git in your server? What host are you using?
Yes, I installed Git. It’s pretty simple to do, compared to everything else 🙂 I installed it on my LiquidWeb server, but DreamHost has it pre-installed on most boxes now. It’s pretty popular with most hosts.