If you want to be a developer, there is something you need to learn before coding. I am talking about Git, a tool that helps you write good code and not screw things up. So, if you want to be a Full Stack Developer – or any kind of developer – you need to learn it. In this post, we will see what is git and how you should use it.
What does a Developer Need?
Instead of throwing at you the definition of git, we can first see why it matters.
Consider the job of a developer, or of a coder. You essentially have to write code, which is just a fancy word for instructions the computer can understand. Like a journalist writes articles and posts, a coder writes code. And, like a journalist, he uses his own files. For example, the journalist will use Microsoft Word and .docx files. Instead, the developer may create JavaScript code in Visual Studio Code and save it as .js files
However, unlike a journalist or a novelist, the coder doesn’t work with just a file. It works with many files at the same time. In fact, an application can be made of hundreds if no thousands of files.
Now, managing many files can be complex, and we saw in this post some great tools to do it. But the problem goes beyond that. If you work with something so complex, even a little change can break everything.
Most importantly, it’s hard to know which little change broke what, so fixing things after can be a real challenge. Imagine you have a complex automatic invoicing application that has code in hundreds and hundreds of files. Eventually, you make a mistake in one of those files, but maybe you don’t notice it straight away. The application breaks and you don’t know where the problem is. Not good.
We need a tool that can help us navigate our code as it evolves over time. A tool that can help us quickly revert back dangerous changes. What is git? Exactly that tool.
What is Git?
We can start with the mundane definition from the official Git website.
Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Okay, if we remove the fuss we end up with this:
Git is an version control system.
Or, better yet, a source control system. So, git is a type of tool to achieve source control. And this, of course, leads to the question: what is source control?
On top of that, remember that Git is a software, something you install on your computer and use it from the command line.
What is Source Control?
Source control means controlling how your source code evolves over time. Like the Captain of a ship will have a journal, every developer has source control. Of course, the source code means all the files that make your application.
Now, let’s get back to the Captain analogy. Our captain sails his boat across the ocean, and every day he logs his coordinates in his journal. If he needs to look back at things, he can just browse his journal.
Instead, our developer doesn’t sail. He spends his day in front of a computer writing code. And, while there is no boat going forward, the source code evolves. For example, in the invoicing application, our developer may add the possibility to include an attachment to the invoice. In a game, he may add the “restart level” button. Or, he may also fix some issues – you get the idea.
Every time he does a set of changes, he notes that in his journal. But he goes beyond that, he also copies all the files, so that in case of issues he can find the code as it was just right after the change was made. As he goes on day by day with more and more changes, he builds several points in time where he can go back to.
This is source control, and git can help us automate that.
What is a Git Commit?
Having a journal like the captain is not something a developer does. Plus, copying all the source code every time is cumbersome, if not even painful. We simply don’t want to do that. Instead, we want a way to achieve the same result easily. This is the git commit.
A git commit is one of the operations you can do with git. It basically tells git that you are at a point in time worth noting. Imagine you are trying to create the “restart level” button for your awesome platform game. You make several tries until you get the result you want. In every try, you have to save some of your code files so that you can test and check if it works as expected. However, those are not meaningful points in time you want to remember about.
You don’t want your journal to look like “I tried this but did not work… then this didn’t work either… and this, but again no luck. Not even the fourth attempt was a success. Oh, finally the fifth time was the right one”. Nope. We want to hide all this struggle because it is not meaningful. We want to end up with something like “Created the restart level button”. As simple as that. And this should represent all our previous tries.
So, whenever you save a file that is part of your source code, you are really just saving it. Now, a git commit is a whole different thing. It basically writes an entry in your journal and indicates which files have changed and how since your last commit. It goes beyond that, it tells exactly how each file changed, line by line.
The git commit is an entry in your journal.
Git Commit vs. Save
Remember, there is a difference between a saved and a committed file. A saved file is just that, you saved it and if you shut down your PC and turn it back on, you will see that file again. A committed file is something that was mentioned in a git commit. You told git “Hey, this file was part of this improvement and has changed since the previous commit”.
You decide when it’s time to save (as early as often as you want), and you also decide when you want to commit. Unlike saving, commit when you reach a point you want to note in your journal.
Now, everything is automatic with git. You don’t need to tell manually which files have changed, git discovers that for you. However, you can exclude some of the files from the commit. This is useful if you reached a good point in time for most of your files, but maybe not all of them.
With git, you can revert back to the code in the state as described by a previous commit. You can’t do that by simply saving a file.
What is a Git Branch?
A journal is linear because the boat can go only in one direction at a time. Each move, each new coordinate is directly adjacent to the previous one. However, this can be a limit for source code. Enters the git branch.
A git branch is the timeline of your commits. Imagine it as a simple line, where the time goes from left to right. Every commit is a point on that line and contains the description of the commit as well as the changed file.
Now, most of the times commits are incremental and sequential. You first create the menu, then you create the options inside the menu and so on. However, this is not always the case.
Sometime, particularly when multiple developers work on the same time, you have more things going at once. While a developer is working on the menu, the other is working on the jump system of your platform game. And those are simply unrelated.
Fortunately, git doesn’t represent the evolution of our code as a straight timeline. It represents it as a tree. So, we can create two branches from our main tree, two paths each with its own commits. Then, each developer will work on his own path. Eventually, when we are ready to ship the game to the users, we can merge back our branches into a single one, and integrate all the changes together.
This can give us great flexibility!
What is a Git Server?
Up until now, we just used git to keep track of how our code evolves. We logged commits every time we made an important change, and we used branches to separate different batches of work.
This is amazing, except for one thing, everything is just on your computer. What if your hard disk decides to stop working? And, most importantly, what is the point of having multiple branches for multiple developers, if they can use just one computer? Enters the git server.
A git server is an online server where you store a copy of your code and all its git information. You store all the branches and all the commits. This is not just a great way to have a backup, it is also a great way to work together with other developers.
In fact, uploading code to your git server is not the only thing you can do. You (or other developers) can also download it, and download its history with it. Besides that, most git servers also offer a great graphic interface (often as a website) to look at the history of code and check for changes.
Of course, your git server can support authentication, be private, available online, or only inside your company. You choose! However, the most common option, particularly if you are starting out, is going with a free cloud provider. They generally offer both private options (code available only to you and other users you select) and public options (code available to anyone on the Internet, great for open source).
If you want to set-up your git online for free, check out these providers:
- GitHub.com (my choice for public)
- Azure DevOps (my choice for private)
- Atlassian BitBucket
Git Commit vs. Git Push vs. Pull
Whenever we make a git commit, we tell git “hey, remember about this point in time”. Git diligently takes note, remember the changes of files, and this is it. It stores the change in the branch you have on your computer.
Instead, with a git push, we don’t tell git anything about the files. Instead, we tell “Hey, take the updates I made to the branch on my PC, and upload them to the server”. You will generally do several commits and leave them on your PC, and then push them on the server once in a while. Most likely, once or twice a day.
The git pull is the opposite operation of the pull. You tell git “Hey, check what’s on the server and download it”. Useful when you want to integrate changes from other developers.
As a tip, push at least once a day before your working day ends. It will act as a backup and you will ensure that, if you are sick, your colleagues can continue working on your tasks. Of course, if your workflow says so, more frequent pushes are welcomed. But less than once a day is not a good idea.
Git Merge (and resolving conflicts)
It will happen. Sometimes you modify a file locally, and when you push it on the server you will find out another developer has committed a change on that file as well. You don’t want to blatantly override the changes.
Instead, you want to check both the changes you made and the ones he made, and merge them together.
This often happens when you want to merge two branches into a single one. This process is known as a pull request. In the request, git analyzes the code from both branches. Now, if there is no file modified by both branches, there is no conflict and they can merge.
However, if one or more files have changes coming from both branches, you will have to check the files manually and edit them before making the merge. Once you resolve the conflicts, you can merge.
What is a Git Repository?
You may work on different projects at the same time, and it’s important you don’t mess things up. You don’t want the files from one project leaking into the other one or vice versa. However, you also don’t want to create a new git server for every project you undertake.
Well, a git repository is just a project in a git server, the set of files that make the same application or concur to the same results. Each server can potentially host as many repositories as you want.
Of course, each commit and branch is related to a specific repository, and only that one. If you have another repository, that will have its own branches and commits. To keep things simple and remember what’s what, each repository must have a name. Easy enough, the repository’s name is the name of the root folder of your application.
What are Git Clients?
Normally, you use git with a git server, using it just on your PC is not much fun. It is like going on a date with yourself. So, you have the git server on one side, and git installed on your PC on the other.
But git itself is a boring command-line application. It can be frightening for a newcomer, and even painful for an expert. You may want something nicer, with a great graphic interface and some nice features.
Git clients are applications that run on your PC and allow you to interact with Git more easily. They allow you to easily make commits, pushes, and pulls. They are so helpful when you have to do merges. If you are wondering, here you have some good clients:
- GitHub Desktop (created by the folks at GitHub.com, my choice)
- GitKraken
- SourceTree (by Atlassian, the same folks at bitbucket.org)
Some code editors come with an integrated git client as well.
Are Git and GitHub the same thing?
No, they are not. However, many newcomers to the developer’s world asked me this question.
Git is the software that takes care of versioning your software. GitHub is an online platform that acts as a Git server. It can host both private and public repositories, and it is the leading place to store open-source code. Of course, being a Git server, any git client can interact with it.
In Conclusion
So, what is git? Git is a source control software that you can use to version your software, collaborate with fellow developers, and have backups in the cloud.
It is a powerful tool that can help you do a rollback when things go south, and it is the industry standard for writing code. You should always use that, whenever you write any code.
