How To Build A Web App, part 4 of ?: Git

Photo by cihan soysakal on Unsplash. I did a Medium image search for “Git” and this bloke came up about twenty thousand times. Search me why. No disrespect to whoever-this-is himself, but I find this specific image so wonderfully pretentious that I just had to include it here. Could be worse, though. Could be Ahmed Angel. Do an image search for him if you haven’t already. You’ll see what I mean.

This is the fourth in a series of articles taking you through all the actual steps in building a web app. If you’re an aspiring developer, if mucking around with teensy beginner tutorials frustrates you, if you’d love to build a properly substantial app that does fab things, these articles are for you.

Last time we installed Rails, then created a new, empty Rails project. This time: version control. Let’s insert our newly created project into a Thing called Git.

What, you may ask, the hell is Git? Read on and I shall explain all.

There’s a bloke called Linus Torvalds.

He once said:

“I’m an egotistical bastard, and I name all my software projects after myself. First Linux, now Git.”

Linus’s personality quirks perhaps lie beyond these articles’ scope, but why yes, he built the world’s current most popular version control software.

Recap time! Like last article, if you already feel solid about both version control and Git specifically, skip ahead to the paragraph: “Done? Great!”

Version control is a way of keeping track of every single change in every single text file in a given folder.

Picture editing a Word document. You type text, you edit existing text, you save your changes. Saving overwrites older changes. They’re lost.

In the past, you may have used a Word doc where, for whatever reason, it’s really important to retain every change you make. Every time you save your doc, instead of updating your Word doc file as normal, you’d instead Save As a new file, every time. Eventually you’ll have many edits and many files, each containing its unique batch of changes.

That’s basically what version control is all about.

In version control, instead of saves, you have things called commits. When you save your Word doc every time, you’re saving the entire file every single time, you’re copying everything, instead of just its changes. Wasteful! Commits, however, record just the changes.

One big difference: our Word-doc model tracks just one file. Version control tracks every file in a folder, including sub-folders, sub-sub-folders, etc. There’s no upper limit to how many file-changes just one commit can record. It’s (usually) better, though, to have lots of little commits instead of just one or two ginormous ones, for reasons we’ll get to in later articles.

Git is one of many different programs that make all this happen. It makes software development so so much easier. It’s not just keeping track of file changes, mind you, Git does a ton of other things. You can create separate parallel universes to build new features in (the cool kids call them branches) to isolate under-construction features. You can send and receive copies of individual commits to specially-built Git-based servers (more on that in later articles). If you want a really substantial guide to Git’s concepts, here’s one. I’ll take you through whatever Git commands we use as we go.

There are a ton of other version control programs around, too, and most are also great. If you’d like to learn more, do check this out. Their pros and cons are beyond this article’s scope, though.

These days Git is the most common. We’ll use that to record our app’s construction.

First, install it. Same as Article 3, with Rails: there are a zillion fantastic resources on how to install Git on your machine, and it’d be a waste of characters to turn them into copypasta. Here’s a good one, it’s from the Git project’s own website. Follow the instructions there. Don’t worry, it’s nothing like as gigantic and appalling as installing Rails. This time it’s just a few commands.

Done? Great!

Next step: Commit One, for our newly created Rails project.

First, navigate to where, in the previous article, you set up your own Rails project “Gigs”. Then, type and run this:

$ git init

Here’s what this does:

git is a command we’re feeding into your command line. We’re telling your computer to run the program Git.

init is a command we’re feeding into Git. We’re telling Git to create a new repository. Basically: “This folder you’re in right now? We shall feed it and its contents into a new repository.”

There’s more in Git’s docs.

Now run this:

$ git add .

Here’s what this does:

Git needs to be told which files we should include for any given commit. I’ll go into the ins-and-outs of that in later articles, but long story short, git add . simply tells Git to include every single new file (which we’d created last time with rails new gigs) in the commit we’re about to make.

Finally, we make that commit with this:

$ git commit -m "First commit! It's about to get real giggly in here"

-m just means “use this next sentence as this commit’s title.” Every commit has a message. This doesn’t have to be “First commit! It’s about to get real giggly in here”, it can honestly be whatever you like. The whole point of a commit’s message, though, is to inform other programmers (including future-you) the commit’s purpose, the changes within it, that kind of thing, so normally I wouldn’t recommend being this flippant. This one is just for demonstration purposes. In future articles, when we code up individual features, I’ll take you through various good practices for commit-message content.

All done! You’ve created your first commit.

I’m making these same commits as I write these articles, and also pushing them to a Git-based web app called Github, so that you can compare and contrast whatever you’re building with my efforts. You can view my version of this first commit here.

PS It was only when writing this that it occurred to me that the perfect URL for an app like this would be gigg.ly. But sadly it is not to be, for some other total bastard is domain-squatting it. Can’t be helped.

Next time: Project management.