Git for non-technical people

I’ve just installed GitLab on a server at work, in an attempt to unify all our separate projects that are stored in various locations. I’ve been a big fan of Git (or rather, GitHub) since I created my first project about 4 years ago. Now everything I do, including various parts of my Aurora Hunting Website, is maintained via Git. Deploying new code to servers is dead simple when you throw git into the fray.

I work in a department that is a mix of programmers, technical-but-not-programmers and definitely-non-technical people. This makes it a bit tricky to explain git in a way that non-technical people can understand. So I’m going to offer an EXTREMELY basic and naive view of what git is. Most things here are going to be anger-inducingly wrong, but this is for someone who has almost zero technical experience.

I’m impatient! Give me the too long; didn’t read version!

Git is a system that tracks who changes files, when they were changed and what changed in them. Changes are sent to a git server that keeps a record. People can make copies of those files, make changes, and send those changes back to be included in the record. It’s mostly used to keep track of who changed code and to allow better collaboration

So what is git?

Imagine you’re walking down the road and decide to keep track of all the neat things you find along the way. This is git. Git watches a folder or a series of folders and takes notice of what files have changed.

When you’ve seen a few cool things (or made a few changes to files), you might want to write them down. This is where a git server comes in.

How do I keep track of the stuff I’ve seen?

You’ll need a place to log the cool stuff you’ve seen so far, so you buy a notebook and write everything in it. It’s a permanent log of what you saw and when.

This is what a git server is. when you’ve lined up enough changes to files, you can push those details to the server for permanent storage. Git servers keep a record of who changed what file and when, plus what was changed in it, and offer a centralised place to store those changes

What if I go for a walk elsewhere?

Sure you could use the same book again, but it’d make sense to have more than one book. Maybe one for walks through the forest, and maybe one for walks through the city? In the git world, this is a repository, and you’d create a new one for each project you were working on.

Makes sense. So why would I want to use git?

Say you’ve got three people working on a single project. What happens if someone changes a file and everything falls into a crashing heap? Who did it? When? What did they change to break it all? Because the git server keeps a record of all this, you can see what was changed by who and when.

Git isn’t just for code either. It can keep track of things like photos and documents, though it won’t be able to show you what changed (because photos and documents with complex formatting and such aren’t easy to compare like text is)

So multiple people can change files?

Yes! Once those files are on the git server, people with the right permissions can come in and make a copy of those files. There’s a few ways to make a copy:


Imagine you’ve invited a friend to join you on your walk. Each person is looking out for cool stuff, but you share the same notebook. When you clone, you make a copy of the files, but each change you send back is recorded under that repository


When you make a new branch, you give your friend a new section in your notebook, and they take notes on their own page when they walk. At any point in time, you can stop and copy what they have, into the main part of your book. When you branch, you’re still operating from the same repository. You’d typically use branches to test new things and fix issues, then when you’re done testing and fixing, you can pull the changes from that branch, back into the main (master) branch.


This is where git gets good. You’re walking down the road, and your friend decides to walk on a different path. You go one way, your friend goes the other. You make an exact copy of your book, and give it to them. Along the way you see some cool things, and you write them down in your separate books.

When you fork on a git server, you’re creating a separate repository. It contains all the changes made up until the point you forked it, but any new changes made go into that forked repository (meaning any changes made to the original repository are NOT added to your change list, and any changes you make are not added to the original change list).

What happens if my friend wants to rejoin me?

Your friend is done walking down their path, so they skip across the field and rejoin you. They want to share with you all the cool stuff they’ve seen so you can write it in your (master) book. In git terms, this is a “pull request”, because the forker or the brancher wants the original repository to pull in the changes they’ve made. The owner of the original repository can say yes, no or ask that changes be made before it’s accepted.

After a pull request is done, the fork can be deleted, or used to make more changes and do another pull request in the future.

Pull requests can be done between branches too, so in order to get your friend’s section of the book merged into the main section, they need to ask you to do it, because it’s your book.

Note that a pull request is one-way. So when your friend gives you all their new information, they don’t automatically get your new information. They would need to explicitly request that. This means that if your goals and their goals change (e.g. they want to focus on cars instead of birds, while you want to focus on birds only), they can give you information without fear of getting a ton of info about birds that they don’t want.

And what about conflicts?

So you’ve met back up and compared notes, but there’s a problem. You both saw the same bird, but your descriptions of it vary. They say the bird was white with blue spots, but you say the bird was black with no spots. Who is right? There needs to be a compromise.

Similar things happen on the git server. If you make a change to file A, and someone makes a change to file A in their fork or branch and tries to merge, which version is correct?

When there is a conflict, git changes the file to include BOTH of the changes. The owner of the original repository needs to go through and resolve the conflict by changing the file so only one of the two changes is in there. Once all conflicts have been resolved, the merge can go ahead.

In the case of our bird, you might put your foot down and say “no, the bird was definitely black”, but you might agree that you made a mistake, and that it had blue spots, and so you amend your notes. Now that that’s resolved, you can copy their info into your book.

Ignoring important stuff

While you’re out walking, you might not want to log everything you see. Maybe you’re only interested in birds. Or maybe you want to log all animals, except those sitting in a person’s yard. In git, you’d create a special file that tells it what to ignore. So if you have a file with passwords in it, you can tell git to ignore that file. Or entire folders, or a mix of both.

Final Thoughts

Hopefully this has been useful for you. If you need to explain git to a non-technical person, this can help. If I’ve missed something, feel free to leave a comment!

Leave a Reply