The importance of using a proper Git Repository along with a quality Git Branching model when building just about anything.

The importance of using a proper Git Repository

I recently worked on a site for an agency who did not have anything set up with with any type of git repository. To be honest, it was really a pain in the butt to work with! It’s not easy to track changes or identify problems when things change on websites without a proper version control system!

What is a Git Repo?

In short, a Git Repository is your project’s code matched up with a historical record of every change ever made to the code.

The record is stored in “commits.” Each commit is a snapshot of your code at a moment in time.

Git offers “branches” which are different versions of the code, and can be developed independently and then merged (combined) into each other when the time is right.

Git History
Example of a Git History, with a Feature Branch

For example, you have your production server running the “master” branch, and you want to develop a new feature like a form which takes user information and stores it in the database.

You don’t want this form being published live until it’s done and all the bugs are worked out. You would create a new “feature branch,” develop the new form, test it out on a staging environment, and when it passes QA (Quality Assurance), you will merge the “feature branch” into the “master” branch and update your production server with the new code.

One of many reasons the commit history is helpful is if something goes wrong, for example.

Let’s say you have three different people working on the site and you need to troubleshoot where this went wrong. You can actually look through all the changes and figure out ‘okay this person did this and then this happened, so now you’ll see they did this particular line of code and that interacted badly with this line of code.’

It’s not to point fingers, it just helps to figure out what the problem is.

Where is a Git Repo stored?

In its purest form, the repo is stored locally, on your computer, in your project folder. It also allows for sharing, so it can sync with a remote storage host.

There are a number of companies/websites that provide this remote storage service. While you can host it yourself, I’d save that for the very advanced applications. Each service provides a different suite of tools to help developers deliver better quality code.

Github is one company, basically the tried-and-true original.

GitLabs is another, which is pretty nice. They provide some tools that help with the whole lifecycle of deployment, so I’ve been looking more into that lately.

BitBucket is good. I like their UI for reviewing Pull Requests.

There a number of other hosts/services, but they are all built around the core essence of the Git package, the historical record of your code.

How do you visualize the Git history?

There are some great, useful visualization tools. gitk is one that’s really lightweight and you can run that from the command line. `apt-get install gitk`

Another one that I like is SourceTree, made by Atlassian, the same company that runs BitBucket. Sourcetree can feel pretty heavy sometimes, but in my opinion, it has the best UI and visualization tools.

Kraken is nice. It has a clean interface, but I found certain simple operations a little more difficult to do easily.

gitk
gitk User Interface

I actually do most of my actual work, like git merge, git pull, git fetch, etc. all from the command line. Once you get used to using the CLI, it’s so much faster and you get a lot more control over what you’re doing. It has a lot more flexibility often with fewer steps once you actually know how to use it.

For a long time I used SourceTree for all git operations. I didn’t know anything about the command line. Then, in a couple of the projects I was working on, I was working with people who were always on the command line in Linux.

SourceTree
SourceTree

I honestly wanted to avoid it for a very long time but because I didn’t want to look like I didn’t know what I was doing, I finally took the plunge.

Now, I drink the Kool-Aid and I have to agree, command line is way better.

I still use gitk because it’s so lightweight, and makes reviewing and searching the commit history far easier, so now in my daily workflow, it’s a combination of both.

One little tip on gitk- change the font and sizing to make it easier to read. The font they use in a fresh install isn’t as pleasing on the eyes.

The ones I use on Windows are:

Main font: MS Reference Sans Serif
Diff display font: Courier New
User interface font: Roboto LT

Why Agencies Should Use Git

Going back to the challenges with my agency client, they didn’t have any repository on the project, so it was a real pain in the butt to work with.  I kept bumping into other developers’ work. Once I installed a Git repo I could actually see the commit history and manage things from there. If somebody was making changes I’d see it. At the very least if somebody made a change directly on the server I would see uncommitted changes that was extremely helpful.

I recommend using Git for ALL projects.

It doesn’t matter whether it’s a tiny, little plug-in or a full website or a large piece of software.

You know if you have your repo in place and you just make that a part of your regular daily workflow on all things. If you do that you’re going to get better quality results.

You’ll have a much more manageable product in the long run.

Freedom