You’ve just started working in tech, and your new employer says “Hey, you know how to use Git right?” You think to yourself “Git?! What on earth is that?”, so you google it. If you find the official description in the Git documentation you will probably be even more confused.
So, what is Git?
Let’s start simple. Imagine you’re writing a letter on your computer and you want someone else to read it through. You could just send the letter to them via email or something, that would work. But what if they want to make changes? How would you know what they had changed? What if they deleted something you’d written, and it was lost forever? What if there’s a whole team of people passing around and working on that same letter? That’s where it starts to get confusing… if only there were a tool you could use to easily share files. Wouldn’t it be great to keep track of who’d made what change and at what point they’d made it? Well that’s where Git comes in!
Git is a Version Control System — it is arguably the most popular tool for sharing and recording changes to files, created by Linus Torvalds (creator of the Linux Kernel). Think of it as recording snapshots of data at specific moments in the history of your files, and being able to access these whenever you want.
Using Git online
There are various online platforms for accessing and using Git, and which you use is up to you (or dependent on your company). Here are a few of the most popular ones:
Each of these platforms, and the many more options that exist out there that I haven’t listed, will have pros and cons; the important thing to note is that it doesn’t matter which you use, Git itself still works in the same way!
How Git works
Git uses repositories, branches and commits. All of the files in your project are stored in a repository. It’s a bit like a folder (but more complicated underneath). It uses branches, which are like alternate timelines, ‘futures which could have been’ for your files. Commits record a specific moment in time on one of those timelines. Think of it like sticking a post-it note in your notebook to remind yourself when you made a particular change or added something new.
When you begin, everything is in one branch. Normally, it’s called “Master”, but let’s keep it simple and imagine we’ve called it branch1 (the original ‘timeline’). You have all of your files in branch1, but you can make a new branch (let’s call it branch2). This becomes a copy of branch1. If you make changes in branch2, it won’t affect branch1 in any way. This is a ‘safe’ way of working — for example, someone can make a new version of your letter and change whatever they want, but the original letter won’t be changed. Think of them as existing in parallel (an alternate timeline).
You can have as many branches as you want! However, I will say that keeping track of your branches is easier the fewer you have 🤣.
An example:
Let’s say that Branch1 has someone else’s letter, which so far only says ‘Hello’. If you want to change it to say ‘Hello, Greta!’ but you don’t want to change the original file, you can make a copy of branch1 and change it there. You’ve only changed the file in branch2; branch1 stays exactly the same.
Now, at some point you might want to change it in branch 1 too, but we’ll come to how to do that in a little while (there are good ways and bad ways of doing it!).
To change back to branch1, and see what the letter looks like there, you can do that at any time by checking out the other branch.
The 3 sections of Git
There are three main sections in a Git project, and this is often where people get confused:
- Working directory
- Staging area
- Git directory
The working directory just means ‘on your computer’. Any changes you make here will stay on your computer until you decide to send them elsewhere. This is my favourite part of Git. You can make changes, you can try things out, you can make a mess and fix it, you can do whatever you want and no-one will know! I think that was my biggest fear as a junior developer — breaking things by accident. Well, with Git there’s no chance of that, as long as you’re careful.
When you move things to the staging area, that is when you have to start thinking carefully. Doing this means that these are things you want to save. It is your way of saying “okay, this is what I actually want to change in the file”. If it helps, think of these changes as people waiting at a train station. If they want to take the next train, they have to move to the platform. They can arrive at different times, but they are all ready to get on the next train. You have to move changes to the staging area if you want them to be included in the next commit.
Once you’ve added these changes to the staging area, you can change your mind and ‘unstage’ the changes — bring them back to your working directory. This is just like in the train station example; if you decide not to get on the next train after all, you can just go back to the waiting room. However, once you ‘commit’ the changes (and get on the train), they have been added to the Git directory.
When they are in the Git directory, the changes have been safely stored in the Git database. *Side note, until you ‘push’ the repository, these changes will stay in your computer. Until the train leaves, you can still decide to get off it!*
When you commit changes to the Git directory, it keeps a record of the changes made, the person who made the changes and a comment from them explaining what the changes are or why they were made. Each commit has a unique identifier, so you can go back to it easily.
What if I’m happy with the changes?
If you’re happy with the changes, and want them in the original branch, what you want is to merge the branches. If you tell Git you want to merge them, it will take the differences from both branches and put them together on one branch.
You can do this manually, by explicitly telling Git to combine all of the changes from a different branch into your current branch. So, if you’re in branch1 and you want it to have the changes from branch2, you can tell Git to merge branch2 into branch1, and you’ll have everything that is currently in branch2!
** Warning! Use this with caution! It is common practice to use your online platform to manage merging branches (normally called pull/merge requests) instead of doing it manually. The platform will take charge of merging for you, so you don’t have to worry about it.
Sometimes the differences will be too confusing, in which case there will be conflicts that need solving. Conflicts mean that Git isn’t sure how to combine them. That’s where you come in. You’ll have to look at the differences and decide which should be kept. Take the letter example again. What if you’d originally written ‘Hello, Greta!’ but your colleague changed it to ‘Hi, Camellia!’, Git wouldn’t know which one you want to keep. So it would say “Hey, there are conflicts! Let me know which version you want to save”.
Summary
Today we’ve looked at the basics:
- Git is a Version Control System.
- You use it to keep track of changes to files.
- It uses repositories, branches and commits.
- Changes to stuff in your working directory stay on your computer — you can stage and then commit changes to send them to the remote git directory.
- To transfer changes from one branch to another, you can merge branches.
But how do I actually use Git?
Now that you understand Git basics, I think you’re ready to learn how to use it! Check out ‘A Beginner’s Guide to Git — part 2’ (coming soon), where I’ll explain what the command line is and how to use Git commands so you can become a total Git badass.
