Explain Git To Me Like I'm Five

Hire 5 artists to all collaborate on painting a picture.

To let them all work at the same time; give them each a copy of the canvas.

After they've painted a small portion, have a painting machine copy their work onto one primary picture.

Copy this primary picture and give a copy to each artist. Each can paint over any part they feel needs improvement.

Again, take the primary picture and the new changes each artist has made and copy it all into a new primary picture.

If anyone feels like the picture was better before, they can look at the previous primary picture or look at each individual's work contributed. We can do this because at each step we copy onto a new canvas and leave all our previous pictures they way they were.

Git takes this idea and applies it to code. Instead of artists there are programmers. Instead of old canvases there are "commits". To track which canvases go together, there are "branches".

Imagine you're playing with Lego, and you've made a thing. Let's say some cool looking monster.

You're looking at your Lego monster and you think "oh man, wouldn't it be ace if I added and extra eye over here?"

So you set about pulling out the bricks and adding in the eye and reassembling the monster. So, a lot of the monster is the same, but there are changes.

Now you look at your monster and you think "wouldn't it be great if it had an extra arm coming out of its back?"

So you set about pulling out the bricks and adding the arm and putting it back together.

And you keep making these small changes, but at some point you find you can't put the monster together because your change has made it impossible to build, and you can't remember how to put it back together in a way that works. Travesty! all that work! and you might have to start from scratch!

If only you could rewind time to the last point that your build worked.

When I write software, it is similar to putting Lego bricks together. When I make a change, it could be the wrong thing to do, so I need a way to get back to a place where the software used to work.

Git allows me to do this, because it will store a version of my code at a particular point in time, and then allow me to rewind time to that point. Because code is stored in a computer, that makes it very easy to make copies of it (unlike with Lego).

This gives me great flexibility, because it allows me to try out many ideas from a common starting point. I can throw away the ideas that don't work and keep the ones that do.

Creating a copy of the starting point to try and idea out from is called "branching". Keeping ideas and pulling them into the common starting point is called "merging".

Because branching is so easy, that means that you can give your code to other people, so that they can try out their ideas.

Merging is easy if the changes in each branch affect different parts of the code. Git can automatically merge the code together in that case. It gets more difficult when the changes affect the same parts of the code. If that happens then you end up with a "merge conflict". The conflicts can be fixed with tools, but it is good to keep changes a small as makes sense to, to make it easier to fix any conflicts.