DEV Community

Kristijan Pajtasev
Kristijan Pajtasev

Posted on • Originally published at Medium on

Version control systems and Git

If you were applying for a development job today, one of requirements would be Git and versioning systems. Something that is so important to development that we can’t imagine working without it anymore. Then again, a topic that is rarely or never covered in any college modules. I remember when I started coding and working on college projects, prototyping, testing out ideas and making changes was pain. This is why I will be covering in this post what version control systems and Git are.

Version control systems

Every project has its start. You start by creating a folder, file and writing some lines of code. But projects grow. They contain thousands of lines of code and often multiple people work on it. Maintaining it becomes messy. Remember when you copied a full project before trying out some change? Naming them project2, project3, project4, project_backup etc. Or working on the same one with your classmate and trying to merge both changes? Really messy.

We all played games, and we never finished them in one sitting. We save our progress and continue the next day, or if we make a mistake, we load our last checkpoint and try again. So why wouldn’t we do the same with code? Well, we do. And that is what version control systems are for. We track progress of our projects with them, save checkpoints so that we can easily go back or see what changed when and by whom or revert some changes if they were wrong. There are many different ones, and each has something specific to it in the way it works, but for all, the end goal is the same.

Git

Git is just one of many different version systems. It was first released in 2005 and at the same time another one was released. Mercurial, which is quite similar. One thing that Git had which helped to get jump start in popularity is its creator, Linus Torvalds. Today, it is the most widely used version control system.

Git commit

Let’s go back to the game analogy. You play a game, you reach some progress and you want to save it. In Git, you do that with git commit. We could say that commit is the state of our project at a specific point. But how exactly does it work in Git? Git tracks only changes between two commits. So if you had one commit, added a line and then made a new commit, this new commit will contain just this added line, and our project is the sum of this last commit, added line, and all commits made before.

There are many actions you can use commits for. One of them is reverting to commit. You save your progress, and continue making changes. But you figure out those changes are not good. Because you saved checkpoint, now you can discard everything made after this commit.

Git branches

Sometimes you have some bigger change. You can’t do it at one go, but maybe it won’t work. Or if you do it just partially, it might break the project. This is why we have branches. It is like a different stream starting at some point in time, from some commit. Git always uses branches, at least one. When you create a project there is always a master branch, and if you just start making commits, they are all made to master branch. At some moment you can create a new branch, This new branch will contain all previous commits plus all new commits made to this new branch. If we would make some commit after branching to the master branch, our new branch would not contain that change.

Once we are done with this new big change, we usually want to combine changes that happened later in the master branch, and those that were done in this new feature branch. We do that by using Git merge. What this does is takes the source branch and applies all commits made in it to the destination branch as if they are made there.

Git origin

You could make a git repository in your machine and just keep it there. You will still be able to use all nice git features like branches and commits. But if you want to work on the project with other people it won’t be enough. You could copy the whole project to another PC. Constantly export changes and send them between each other to import. But that is far from ideal. What you will have is some centralized place where your project data will be stored, and from where you will download changes. And it is also a place where you will upload all changes, commits, you made. Like that any person that works on a project will easily be able to get your changes and send you theirs. That location where it is hosted is called origin. You can set it on your own personal server, but there are also many free solutions you could use for this like Github.

Conclusion

There are many features to be covered and explained about Git. How to exactly commit something, send changes, merge and many more. But what I do hope that what you got from this post is understanding what it is. When looking at version systems for the first time, it can be confusing, and I do hope now you get an idea how it works and why it should be used.

Top comments (0)