Here we are trying to explain Git’s function in short. Let’s begin our exploration of Git, by gaining an understanding of what it is and what it can do. Please note that all questions and answers are based on our research and self-study. If you missed the previous articles on our site please visit once.
What is Git?
Git is a mature, actively maintained open source project originally developed in the year 2005 by Linus Torvalds, he is the famous creator of the Linux operating system kernel. We can say that Git is software that keeps track of changes that we make to files and directories of a project. And it’s especially good at keeping track of Code changes. A number of software projects rely on Git for version control.
Version Control
Let’s imagine that you have a document. You start with version 1 of that document and You did some changes to it, and now you have version 2. And you make some more changes and you now have version 3. Git keeps track of those three different versions for you. It allows us to move back and forth between the versions. And to compare the different versions to see what changed. Git is referred to as a version control system or VCS for short.
Git’s not the first version control system ever created, there’ve been others. And almost all of them had one primary purpose, to manage source code. Programmers wanted a way to be able to track the changes that they made to computer code over time, as they added features and as they fixed bugs. So they created version control. Because of this, they’re also called source code management tools, or SCM for short. IF you’ve never worked with source code management tools before, you have likely worked with other types of version control. For example, you may have had different versions of files, and given them different names so you can keep track of the versions. So you have a budget that you’re working on and have version 1, version 2, and version 3, so you put a little text at the end of the file name to let you know which version this particular file is. Then found some mistakes and you called the next version final, final version 2, or really final this time. Many applications offer some form of version control as one of their features. For example, Microsoft Word allows you to track the changes that you make to a document. You turn on the track changes feature, and send the document to someone else. They make changes to the document and then when they send it back to you, you’re able to review their edit as well as see the original version. If you’ve ever worked with a Wiki, like Wikipedia then you’ve used a form of version control. When someone contributes a change to a Wiki page the editors have the ability to undo that change. They can go back to a previous version if they need to. We call that process rolling back to a previous version. And of course, we’ve all done the most simple type of version control of all, undo. Ctrl+Z on Windows or Cmd-Z on a Mac. It’ll undo something that we typed or a change that we’ve made. It allows us to go backward and even undo multiple changes. These are very primitive examples of version control. And there’s no substitute for a real version control system, like Git. But they do provide useful metaphors. They’re examples of how to track and view different versions or changes over time. And how to move backward and forwards in history to undo or redo those changes. That’s what we’ll be doing with Git.
The History Behind Git
There are five important version control systems that predate Git.
- Source Code Control System (SCCS): It is quite popular. It was released in 1972 and was developed by AT&T and it was bundled free with the Unix operating system. Now Unix was also free, and as a consequence, Unix spread quickly to places like universities and SCCS went along with it. Universities taught their students how to do version control using SCCS so when they left the university to go work in jobs, the version control system they were familiar with and that they took with them was SCCS. So you can see why it became very popular. As per the above example SCCS does is it keeps the original document, but then instead of saving the whole document a second time, it just saves a snapshot of what the changes were. So if you want version five of a document, you just take version one and apply four sets of changes to it to get to version five.
- Revision Control System (RCS): it was cross-platform, whereas SCCS was Unix only. With the rise of the personal computer, it was important to have a version control system that would also work on PCs. It was also more intuitive and had a cleaner syntax with fewer commands, and more features. Most importantly, it was faster, and a lot of the speed increase came from the fact that it used a smarter storage strategy than SCCS. Remember SCCS stored the original file and then kept track of all the changes to that file that went after it. RCCS flipped that around so it kept the most recent file in its whole form, and if you wanted to go backward in time and you wanted previous versions, then you applied the change snapshots to go in reverse. If you think about it, that’s a lot faster because most of the time, what we want to work with is the current document. With SCCS, if we wanted the current document and there were 20 sets of changes, you had to git pull up the original and then wait while 20 sets of changes were applied. With RCS, we can just bring up the current file, and it’s already stored in its full state. One of the problems with both SCCS and RCS was that they only allowed you to work with an individual file one at a time. So you could track changes in a single file but not in sets of files or in a whole project.
- Concurrent Version System (CVS): It allowed us to do that. Now the real innovation in CVS is not just the fact that you can work with multiple files, it’s the concurrent part. The fact that we can have a place where we can store our code is called the code repository and you can put that on a remote server and more than one user can work on the same file at the same time. They can work concurrently. In previous versions, only one person could work with a file at a single time. So CVS adds a lot of features for users to be able to share their work and be able to update their files with changes that other people have made and placed in the remote repository.
- Apache Subversion(SVN): SVN was faster than CVS and it allowed the saving of non-text files, like images, where CVS couldn’t do that. Most importantly, the big innovation of SVN was that it was tracking not just changes to single files or to groups of files, but actually watching what happened in a directory as a whole. Watching files and directories collectively and actually taking a snapshot of the directory, not just the files. SVN though would track that change with no problem. If you add a file, remove a file, rename it, it’s watching the directory as a whole to see what happens and taking a snapshot of that where CVS was just looking at a collection of individually named files.
- BitKeeper SCM: It was a closed source proprietary source code management tool. That means that a company owned it and sold it the same way that Adobe sells Photoshop or Microsoft sells Word. One of the important features that BitKeeper had, and it wasn’t the first to have it, is distributed version control.
FAQs:
Q. What is NOT a way to use version control?
Making changes to an image file and saving the new version to the same file.
Without saving previous versions of the file separately, no changes are tracked.
Q. How might users make use of Git’s version control capabilities?
A development team can use Git to evaluate version differences prior to new changes to the production codebase.
Example: Git’s strengths lie in its ability to allow multiple users to contribute to a repository, and the repo owner can easily evaluate proposed changes with Git’s tools.
Q. Why is Git so much more powerful than earlier version control systems?
It is fast, can handle large codebases, and is distributed.
Example: Torvalds needed Git to work well for Linux, so it needed to be fast, handle the entire kernel base, and be accessible to the open-source community.
Q. What is the effect if a file in the main repository becomes corrupted?
There is no effect on users’ local copies.
Example: Because Git is distributed, the file in users’ repositories will be unaffected by any changes to the file in the main repository unless users attempt to retrieve the corrupted file.