The tools we wield define us, git is the one tool all developers use

Git is a ubiquitous version control tool. The way it works tightly correlates with software engineering and the mindsets of developers. It was purpose-built and designed to be used for the development of the Linux Kernel, one of the largest software projects that’s depended on by millions of developers.

Your editing workflow is painful because it’s not version-controlled

As part of a team, your editing workflow probably consists of sending a file back and forth for review, comment and amendments. In a programmer’s eyes, this is a crazy inefficient way to work. In addition, the likelihood an edit will be lost or overwritten is high.

With git, that doesn’t happen any more. If only everyone used git, no more lost comments or amendments.

That’s wishful thinking of course but understanding how git works with branches, commits and so on will help you use the tools you already use more efficiently.

Reflexes like using the “latest” version of the document and re-applying your changes to it methodically will radically change the way you approach collaborative editing.

Designed for a distributed team

In a remote, remote-friendly or a company that outsources any work, you know how long and arduous the revision process can be. Git was designed to help this process, many tools in the ecosystem around git have a concept of grouped changes that should be reviewed together (what GitHub calls Pull Requests).

Git becomes your one source of truth, everyone has it locally but it’s also all online.

Proven solutions to scale problems

As one person the versioning process is “easy”. Adding another contributor can change the way you work massively. Now imaging going from 1 to over 1,500. That’s what the Linux Kernel did, from just Linus to thousands of contributors from companies such as Intel, IBM and Samsung.

Processes around git allow it to scale with your team and your project. Workflows like taking a section of work and integrating it after review are great even if you’re not using git. Having a version-control mindset and approach to this problem will help even with the less than optimal tools.

A complex tool with simple actions: the UNIX philosophy

Git is actually relatively complex as a tool. Most of it was designed under the UNIX philosophy that tools should do one thing well and then be composed (or strung) together to do more complex actions.

This stands quite true of git despite not being true of all the actions you may run. Some things aren’t quite intuitive but they’re there if you remember them.

Git wraps concepts that most non-developers can grasp in developer-friendly packaging.

Due to the accessibility of version control as a business problem, learning to use git is an introduction to the command line that is more understandable. Non-developers could probably see themselves using git (even if they never end up doing so)

Working in the Open

Open Source projects usually use git and hosting platforms like GitHub, GitLab or BitBucket. The first obvious project to use it is the Linux Kernel, which is one of the biggest Open Source Software projects out there.

Understanding git means you understand how developers from around the world in different timezones and with different backgrounds can collaborate.

Hopefully you now understand how git can be considered more than just a version control tool.

If you want to learn more about git, I’ve written a course specifically for this purpose, you can find it at the following link for free if you sign up: Git for Creatives (http://skl.sh/2zNN3En).

Feel free to get in touch with me on Twitter @hugo__df.

Leave some ❤️ if you enjoyed this.

Originally published at codewithhugo.com on Dec 4, 2017.