Features of Git

Now that we have covered the basics of version control systems. And have also seen how Git records changes to files over a period of time. We can now take a closer look at the features of the Git version control system. We will stick with the tea recipe example we have been working with so far.

[Video description begins] Screen title: Working on the Source Files [Video description ends]

And let's just say all of this needs to be stored within the Git version control system. When working with Git, you would create something known as a repository. This is effectively a container for your source code, and typically users create one repository for each project. In order to share your source code with your broader team, and potentially with the general public, you could create such a repository online. And as we have covered already. Different versions of your source file will be saved as the original version of the file, followed by a series of modifications. Now if it is someone else who has developed the source code and you need to begin working on it. You will likely need to get the latest version of the source files. And in the case of our tea recipe, you know that version three is the latest version. And it can be recovered by taking version one and then applying the changes. So this is the latest version of the file which you have downloaded to your workspace. And with many version control systems it is only this version which you can download locally. It is the online repository which contains all of the previous versions. This is not how Git works, however.

[Video description begins] Screen title: Git [Video description ends]

I'm going back to the definition, which we saw earlier on. It is a distributed version-control system. What this means is that we have what is called a remote repository.

[Video description begins] Screen title: Remote Repository [Video description ends]

Which is online and contains the original source code, followed by all of the recorded changes for each file in the project. For anyone who wishes to start development work on this project. Well, they can simply copy over this remote repository into a local repository or local repo for short.

[Video description begins] Screen title: Local Repository [Video description ends]

What is significant though is that you don't just download the latest version of the source files but the entire recorded history. Which is why in Git terminology, when you copy over a remote repo to your local machine. What you have done is clone the repository into your workspace. So this local repo is now exactly the same as a remote repository, which means that there are now multiple copies of that repo. In other words it is distributed and this is how Git is referred to as a distributed version control system.

[Video description begins] Screen title: Source Code Development [Video description ends]

The benefit of such an approach is that it is possible for a developer to record, in other words, commit their changes to a local repository. Even when they are offline. So in this example, consider that the remote repository has the original source followed by four changes. And the developer who has cloned this repo over to the local machine has now recorded a fifth change. Well, let's just go further ahead and then record a sixth change as well. Since this local repo works pretty much exactly the same as the remote one, these changes are recorded in exactly the same manner. Which means that this developer can revert to one of the earlier versions. If they feel that the changes which they have recorded need to be rolled back. So developers have all of the benefits of a version control system, even when working offline, since they have a full-fledged local repository. At some point though, the developer will be ready to share the changes which they have made to the source code. So they will need to copy over all of the changes which they have recorded from their local repo over to the remote. And this process in Git terminology is referred to as a push. So to summarize, this whole process started with a developer cloning a remote repository and thus creating a local repo. He then made changes to the source files. And then they recorded these changes in the local repo in the form of commits. These commits can then be pushed over to the remote repo. And when that happens, the remote repo and the local repo are in sync. So we just covered some of the fundamental operations when working with the Git version control system.

[Video description begins] Screen title: Features of Git [Video description ends]

With that said, let's take a look at some of the overall features of Git. We have already covered the fact that it is a distributed version control system. Each time a developer begins work on source code which is stored in a Git repo. They will need to create a clone of the repository which means that they end up creating a distributed copy. Another important feature of Git is that it is both free and open source. Which is certainly one of the reasons for its widespread adoption these days. Beyond that, it is also rather small. And importantly, all of its operations are rather quick, especially when compared to older version control systems. While all of this makes Git rather simple to use, it also includes features which make it easier for you to build robust code. For example, Git supports the concept of creating branches of your repo and then merging those branches into your main source. This topic of branching and merging is something we will explore in greater depth in the next video.