Git: A Content Versioning System
Git is a hugely popular Content Versioning System dating back to 2005. While it’s not actually an acronym, “Get It Together” does fit rather nicely. With a git “repo”, a codebase will track
- A note from the developer for each set of changes to the code
- Which files were added, deleted, or changed (down to an individual line number)
- Who made those changes
- When those changes were made
Developers can see what the code looked like years previous compared to now. We can determine when a feature was added, when a change was made, and who made that. It arms a development team with knowledge of an application. And knowledge is power efficiency.
How much does Git cost you, the client?
Git is a free program and it saves you money. It saves money by saving developer time. The savings increase the more complex the project is.
Yes, using it takes time. Companies build workflows using Git as a critical piece. So it doesn’t come without cost. Most noticeable is for tiny changes. Why does it take so long to change a color or modify one tiny thing? It’s because that tiny, one-line-of-code change had to make its way into Git.
But that’s one end of the spectrum. Git also arms developers with knowledge of the project. Each time the code is changed, there’s a note written by the developer like ‘Adding in Feature X”. A future developer can look at that note and find out exactly which files were added or changed to make that feature happen. Making it easier to find what they are looking for when a new change is requested.
What about time? Does Git delay a project?
Short answer: no.
Even if it’s just a single developer. The efficiencies to that one developer to help organize outweigh the minimal amount of time it takes to use.
Git also allows developers to work as a team. Each developer on the team has their own copy of the git repo which contains the entire history of the project. Git provides tools to combine and review these separate copies.
What is Git and why should you use it?
Developers at CommonPlaces use git more often than Star Trek solves problems by reversing polarity. It’s part of our daily routines, our workflows, and very habit forming.
Developers rarely agree fully. We love debating with each other. Developers find coding to be a creative exercise. And like any art form, it requires practice and sometimes feedback. We are always striving to create elegant, beautiful, and reusable code. Git helps. It helps reduce bugs, increase consistency, and solve problems. It does all this while providing tools for developers to work together.
Less bugs, more consistency
When a CommonPlaces developer is working on a complex task, we’ll work our magic on the keyboards. But before that new code can make it onto a live site, it’s submitted via Git for review. Then another CommonPlaces developer will review it. This can go back and forth until both developers agree it’s all good. This is a great method for finding bugs and ensuring that code created by CommonPlaces has consistency, no matter which developer started the work.
When Git Conflicts Occur
Oh god, oh god, what have I done? These are words seldom heard. But it does get said on occasion. It’s also a reason we don’t work on production sites. So phrases like this happen away from the public’s notice.
Thank goodness we use Git! Git will tell us EXACTLY which files and what lines were changed in the code. So we can easily go back a minute, an hour, or even a year if needed.
Who’s to blame!
A developer can read a line of code and thinks, “Who did this? What on Earth were they thinking?” Luckily with the power of Git, we can run a command called Blame. Seriously, that’s what it’s called. We can find out who and when that line was made. Knowing the history and what other files were changed at the same time helps us solve the problem quicker.
- Was it me? What was I thinking? It must have made sense at the time. Is it OK to be angry at my previous self? Is 6-months-ago-me really that different from current-time-me? It’s a philosophical conundrum. But in the end, it’s a lot like stubbing your toe; you can’t get mad at anyone but yourself.
- Was it the Developer sitting to my right? Cool, I can now ask them WHY they did something a certain way. Or point and go “ha ha” before solving the problem.
Summary time
Why is Git (or any version control) awesome sauce?
- It allows workflows that fit the team
- It allows code review – leading to better code
- It retains knowledge of your codebase. And knowledge is power that can save time.
- It’s a best practice
Is your agency using Git in their workflow?
