Embracing Git

If you're an experienced Git user this article probably won't be of interest as it's intended for those who may be on the fence about using version control. Rather it's a brief (and not too technical) overview of Git and an insight into why I took the plunge and what my experience has been so far using Git for web deployment in place of (s)ftp.

Git Curious?

If you're like me — or how I used to be — you're probably reading this because you've heard of Git but aren't exactly sure what it's for, how it works or why you would want to use it.

There are numerous well-written articles that explain in painstaking detail the über technical aspects of version control. Step-by-step how-tos for developing a Git-based workflow including all the command-line tips any sane person could ever want, so I see no point in rehashing what has already been thoroughly documented elsewhere. But sometimes when trying to decide if a workflow is right for you a simpler explanation is better.

Before we get started, and in the interest of establishing a baseline understanding for this article, here's a basic Git overview for those who may already be scratching their head.

• Git is a Version Control System (VCS), sometimes referred to as Source Control Management (SCM) which is the parent term that encompasses more than a VCS. A couple other popular systems include Mercurial and Subversion. First and foremost they are applications used to track, store and manage the state (or revision) of a file. When you edit a text file the changes are stored in a database and can be accessed or restored later. A VCS is typically used to manage website and software development but it's also a perfect tool for writers.
• The heart of a VCS is its repository (repo), a central location from which users can search, Add (new files), Commit (file changes), delete/restore revisions and, if this is your goal, deploy to a website. A repository can be setup locally on your computer, on your own remote server or with a dedicated repository hosting service (see below).
• Any number of users may be given access to the repo.
• The local and remote repos communicate with one another so changes can be easily “Pushed” and “Pulled” so you always have the latest revisions no matter how many people are editing. Where this typical scenario may differ is if you only work locally (or work alone) and have no need for a remote repo.
• A VCS is frequently used in lieu of (S)FTP to update a website. Instead of “Publishing” or “Uploading” files to a server you “Push” revisions from a repo to the server which replaces the current site file(s) with those from the repo. Commonly referred to as “deployment” in VCS-speak. This type of workflow typically (but not always) requires 3 repos: local, remote (usually hosted), and a clone of the remote repo on your own server, though you only interact directly with two. See below for an explanation.
• A VCS excels at collaborative workflows, this really is its milieu, though by no means do you have to use it in this way. Singles are welcome.
• Files and folders can easily be kept out of the repo with a .gitignore file.
• It's possible to compare different revisions of a file (using the command line) to see precisely what changed using the git diff command. If you'd rather use a 3rd Party diff application, e.g. Kaleidoscope — by far the nicest but also the most expensive — it's a simple matter to set it as the default “difftool”.
• Existing files can be branched (thus creating a new file) which can be independently modified by anyone and, if desired, be merged back into the main file at anytime. Branches and merging can be immensely useful, it makes organizing projects easier as well as providing a safe environment for parallel testing and experimentation.
• Files can be edited by any number of users from any geographic location, though there are ways of setting up a collaborative workflow that should be observed in order to prevent problems.
• There are online hosting services where you can setup a public or private remote repo, the more popular being: GitHub (Git; free and paid), Bitbucket (Git and Mercurial; free and paid) and Beanstalk (Subversion and Git; paid). Such services are very useful for sharing public code as well as managing private projects and users while serving as a hub between the local repo and your server.
• Many Git users use the command-line which isn't nearly as intimidating as it may sound but it's not for everyone. Don't worry, the past couple years have seen an explosion of Git clients that provide a simple and beautiful graphic interface from which you access your local repo as well as those hosted on the above services, and many are free!
• Finally, you will need SSH (Secure Shell) access to your server so the remote repo (GitLab, Bitbucket, GitHub etc.) can safely communicate with your server. This involves generating SSH keys. While not terribly difficult this part more than any other in the initial setup process can sometimes be confusing for new users but there are excellent instructions available.

Now that we have covered the basics of what Git is and does hopefully it will help put the rest of the article into the proper context. Read on.

Dragging My Feet

I’m pretty good at staying informed about the latest web-related technologies and workflows but I don't always adopt them simply because the propeller-beanie majority say I should. That’s not to say I won’t, only that I like to investigate them at my leisure. Git falls into that category.

I'm not completely new to version control having had a flirtation with Subversion a few years ago which sparked my curiosity with VCS. In fact, I've been playing around with Git for some time which is why it's kind of funny that I've taken so long to commit (pun intended) to using it.

It’s no secret Git has ruled the roost for some time, and along with the über popular social coding site GitHub it has handily set the standard for how people share code and collaborate both professionally, and more surprisingly, socially. Github has a very large and active community; a specialized social network of sorts (but in the best sense of the term) for everything code-related.

Not Just for Geeks

It's easy to dismiss Git as “for geeks only”, useful only to hardcore coders which is no doubt its core user-base. But I'm a designer who codes and I think for others like myself it's a marvelous tool, not to be summarily passed-by as unnecessary for designers. It's also worth noting that version control is not the exclusive domain of developers and designers, it's an invaluable tool for writers or anyone who needs to track changes to any text file.

Move Over (S)FTP

Ok, I admit it, I’m a recovering (S)FTP user. I like (S)FTP, we've been good friends. It’s simple, straightforward and serves my deployment needs just fine, but apparently the “cool kids” have deemed it sooo last decade.

As I understand it Git was not intended for use as an auto-deployment tool even though it often is. But as is the case with most things I think it depends upon the context in which it’s used. There are a great many scenarios where auto-deployment would be a very bad idea, but sometimes it’s a perfect fit for uncomplicated one-person projects. So while some Git purists may balk at the idea it does have its niche uses.

Git It (get it?)

Have you ever edited a file only to realize weeks, months or even minutes later you want or need to revert to a previous version but you can’t recall exactly what that version is? Me too. This is the most compelling reason (to me) for using version control.

A big incentive to try Git, aside from a growing curiosity, wasn’t because I needed version control, but rather because it’s integrated into Coda 2 which I use almost exclusively for front-end work. In fact it's the same reason I tried Subversion a few years ago. However my first experience with Git left me somewhat unimpressed for a couple reasons:

• There are more steps required to get local changes onto the live site. When adding new files to the repo the process is Add > Commit > Push. For existing files it's Commit > Push. But when compared to simply hitting the “Publish” button in Coda and having every modified file uploaded then yes, it is more work. This is especially apparent when several files have been changed and you need to commit each one separately.
• Speaking of commits… without a useful commit message¹ you’re essentially missing the point of version control. A commit involves typing a brief but informative message for for each changed file², clearly something FTP does not require. At first this can be offputting, especially when it’s only you using Git; the clicks and keystrokes add up fast. And this is supposed to be better than FTP?

Typical Git Workflow

At this point you may be saying, “Ok, it sounds interesting, but how do my local changes end up on the remote site without FTP?” That’s a good question and not one I figured out right away, but more on that in a moment. Here are the basic steps of a Git-based (web deployment) workflow:

1. Edit a file in the local repository (ie, on your computer).
2. Commit then Push changes to the remote repository (usually to a service like GitLab, Bitbucket, GitHub etc,).
3. At this point the remote repository in Step 2 is updated and — if an auto-deploy script is used — the revisions are automatically Pushed to the cloned repo on your personal server and the website files updated. All of it completed securely and almost instantly.

As I said at the beginning there are 3 repos involved. Yeah, I hear you saying, “Three?! Shit, that's a lot.” I thought so too. But before you move on it's worth noting this isn't nearly as complicated as it sounds, in theory or practice. The cloned repo on my personal server is created as part of setting up my remote (Bitbucket) repo and is trivially easy to do. You won't need to interact with it directly so once it's created you can safely forget about it. Just don't delete it!

Alternatives?

What if you don't want to use a hosted repo service? Well, the Git application/source code could be installed directly on your server thus negating the need for a service like GitHub etc. However, I suspect there are technical hurdles involved in going this route, not to mention many — perhaps most — web hosts won't allow it on shared hosting plans for security reasons which puts you back at square one.

If you're on a VPS (Virtual Private Server) such hosting restrictions don't come into play and you can customize your server to your heart's content, but for most of us services like GitHub and Bitbucket make for a nearly pain-free setup because they've already done the technical heavy-lifting.

Baby Steps

As is the case with anything new there’s a transition period which can be irritating but once I moved past my initial frustrations, mainly with typing commit messages, the benefits mentioned above became obvious. However I wasn’t quite there yet.

I still couldn't stop using FTP simply because I didn't know how to Push the changes from the remote repository (in my case, Bitbucket) to my website. Fortunately another useful aspect of Git is something known as Git Hooks which allows for additional functions to be automated with scripts. One of the more convenient (necessary?) being — in a non-FTP workflow — auto-deployment, which is what I use to automatically Push changed files from the remote repository directly to the server/site. Strictly speaking it’s possible to do this part manually but who wants to? For me this is an indespensible feature and once I got it working the stars aligned and everything was cashmere and purring kittens.

The Verdict

I went into this with the mindset I didn't need version control but I've gained a new perspective. I wouldn’t go so far as to say it’s necessary for every project because it could easily be overkill. That being said, when appropriate the benefits clearly outweigh the extra work of typing commit messages or a few more mouse clicks. There have been numerous times when I've needed to compare and/or rollback a file and this alone has saved me hours of guesswork. And that's just one aspect of a much bigger picture. I've also been experimenting with branching files so I can safely kick around new ideas. It's been both fun and productive.

You may have noticed my previous post about the CSS preprocessor Sass which is another tool I’ve been aware of for some time but have only recently fully embraced as an integral part of my new workflow. Used together both continue to improve my overall efficiency with managing projects and writing code. Newly armed I feel better equipped to work in the ever-changing technology-driven landscape we designers and developers choose to work in. I'm not sure how I managed to work so long without Sass and Git but some things do live up to the hype.

1 A commit message is a brief write-up of the changes made to a file. An acquired skill itself.

2 Multiple files can be committed at one time with a single message but rarely have I found an opportunity to do so. The exception being the very first time you commit a new file to the repo, known as an “Initial commit”.