When you’re from a dev shop that’s been around for over a decade, have proven procedures and processes plus a fairly large team that love the way things are done, change is difficult.

But this was all disrupted recently when a few of the agency’s forward thinkers started discussing the idea of changing the team’s daily workflow to include Git. There was definitely some understandable push-back, so I’m posting some of the reasons we decided to move to Git, because communicating the why behind a large transition is always necessary.

My hope is that this summary will help other teams trying to make the transition.

Let’s get the Git terminology sorted

Easiest to think about a repository (or repo) as a project’s folder. A repo contains all of the project files (including documentation), and stores each file’s revision history.

Contained within a repo, consider a branch like a duplication of all files within the repo to a new folder so that you or another collaborator can work on the project. Perhaps it’s a new feature or hotfixing a bug. Branches allow collaborators to work on the code without disrupting the “live” version. When you’ve made the changes you want to make, you can merge your branch back into the master branch to publish your changes.

Merging takes the changes from one branch (in the same repository), and applies them into another branch. Eg. you’ve created a branch to build a new feature, you’re finished so you merge your code into the main code.

A commit, or “revision”, is an individual change to a file (or set of files). It’s like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the “SHA” or “hash”) that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.

A push refers to sending your committed changes to a remote repository such as GitHub.com or BitBucket.org. For instance, if you change something locally, you’d want to then push those changes so that others may access them.

Pull allows you to fetch in changes and merge them. For instance, if someone has edited the remote file you’re both working on, you’ll want to pull in those changes to your local copy so that it’s up to date.

Cloning allows you to copy a repo to your computer so that you can start working on the code. It has a link back to the place you cloned from, so that you can push code back to the main repo.

Checkout refers to the action of switching between branches. Because you can have multiple branches going at once, you’re able to checkout different versions, which switches out the code for that of the destination branch.

So…What is Git?

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses other tools with features like cheap local branching, convenient staging areas, and multiple workflows.

Basically, Git is a way to manage code versioning. So engineers can write and test their own version of the codebase (branch) which won’t disrupt anyone else. They can continue to commit code back to the central repository. If anyone wants to integrate anyone else’s code (be it back into the master version or just into their own branch), they can seemlessly merge code into another branch.

That paragraph alone should sell you on the benefits over no version control.

What has Git improved?

1. Collaboration — The ‘multiple engineers at once’ issue

There are many times we have a front-end and back-end engineer working on a project at once. This leads to a few issues:

  • Do you have this file open? Can I open it? Can you close it? I’ll be 1 minute with it.
  • What did you change? It wasn’t like that when I left it!
  • He broke it!

These were everyday problems before using Git.

With Git, engineers can create their own branches — the front-end can have his and the back-end can create her own feature branch. When the feature is finished, the front-end can merge the new feature into his branch and start styling it.

2. Accountability — The anonymous ‘fairy broke this’ issue

Everything in Git is logged as soon as code is committed. This helps keep engineers accountable for:

  1. Introduction of issues/bugs
  2. Work completed in a given period

Whether a front-end is claiming a back-end engineer broke a feature or you’re trying to track down who added a malicious snippet of code — Git allows full transparency as everyone can see a diff of which code was changed when, and by who.

3. Deploying changes — The ‘which files do I need to upload’ issue

If you’re not using Git, you know this one well. You’ve been tasked with making adjustments to a live site. You’ve made those changes locally over the past few weeks and they’re now ready to go live. Did you write down every file you changed? Are you confident your list is 100%? You didn’t miss one file did you? Ok now to upload each file one-by-one…

Git knows what has been changed and which files need to be sync’d to get the live site up to date. It’s all automatic, quick, cheap and painfree.

4. Disaster recovery — The ‘we don’t have a backup’ issue

Unfortunately there’ll be times when a site is hacked and malicious code is injected in every file (I’m looking at you o’ vulnerable WordPress). Or a hard drive fails on the live server. Yes you may take backups — but what about when the issue isn’t noticed for a month and the rolling backup has been overwritten?

With Git — all code goes through the project’s Git repo, so at any time, you can simply deploy from the single bucket of truth that is your centralised Git repo.

5. Disposable experiments — The ‘it’s working, I don’t want to break it’ issue

If you’re not using Git, and you want to try a new framework or make a change that will potentially break your codebase — what are your options? You’d probably say ‘copy the site to a new directory, try it, if it works, the new duplication is the most recent version’. Or even ‘make the changes, don’t shut down you text editor — if it doesn’t work: undo, undo, undo, undo…’.

This doesn’t encourage experimenting or even provide a platform to innovate.

Git allows you to create a completely separate branch (a cheap and performant duplication of the code) which will have no affect on the main codebase until you want it to.

6. Code documentation & management — The ‘I can’t remember how it works’ issue

By using Git with platforms like Bitbucket.org or Github.com — you get three essential tools for each repo:

  1. Readme.md — a file that should explain what the project is and does, system requirements and how to get started
  2. Issue tracking — Anyone with access can add an issue, comment on an issue, assign an issue to a user and prioritize issues
  3. Wiki — a central hub to document how everything works within the project — whether it be a list of all API endpoints or just ‘I had to do this hack because of XYZ’. No need for additional tools — it’s all together alongside the code

Having these tools available for free alongside your code provides a convenient way to take your quality standards and code accessibiliy up a notch.

7. Work from anywhere — The ‘I don’t have easy access’ issue

Consider this — the website you’re working on is on a single development server in your office. You want to work from home. You’d need to setup and gain access to a VPN, then download the files from the server to your home computer. Then when you’ve finished, bring in those files to the office and copy/paste the files over the top. This whole thing seems so dated — we’re tech professionals aren’t we?

Setting up a project on any computer is so much simpler when using Git — simply clone the repo. Then when you’re back in the office — just pull the changes — lightning fast.

8. Multiple feature releases — The ‘I hope I don’t break anything’ issue

Picture this: Your company isn’t using Git and you’re all working of a single development server (more convenient right?). You’re working on a large project with multiple engineers. You’re working on feature X to be released next week, a colleague is working on feature Y which won’t be ready for a month. Due to the features, you’re both working on a few of the same files. Ok — time for you launch your feature — but DON’T launch your co-worker’s changes! Kinda hard hey?

Using Git, you could use feature branches and simply merge your changes into the master to launch.

9. Rolling back — The ‘oh crap, is there an undo?’ issue

Finally, one of the main reasons to use a version control system like Git — the ability to rollback when mistakes are made.

I’m sure you’ve had those moments using FTP when you’ve:

  • Dragged a file to the live site then realised you shouldn’t have replaced that file
  • Uploaded a file to live, only for it to bring down the site or introduce a bug

Firstly, the practice of a Git workflow enforces another layer of testing using the live code (you don’t have out of sync codebases). Moreover, the technology of Git allows you to quickly rollback to a previous version of the codebase very quickly if the issue were to happen.

Matt Mcnamee

Author Matt Mcnamee

More posts by Matt Mcnamee