Git in Less Than 10 Minutes
Git is a version control system that is typically used with software projects to keep track of all the changes made by everyone having access to it.
We will go through it in more depth and understand where we can use it, as well as a simple tutorial on having your very own Git repository.
What Is a Version Control System?
Before we dive into Git itself, we need to understand what a “version control system” is. It is a system that allows you to keep track of all the different changes made in previous “versions” of a file or of multiple files.
Let us say you have a document that you wrote 2 weeks ago and updated it 1 week ago. You realized that you accidentally removed important information last week and want to view it. Here is where a Version Control System, or VCS, comes in handy. It will allow you to see how the document looked like when you first created it and will allow you to view the changes you made to it last week. All the details will be there.
What About in Software Development?
Now in software development, it works the same way. Let us say you worked on a feature last night, then you woke up this morning and suddenly it was not working properly. You can check all the changes that you made last night to see what possibly made the application fail.
In software development, we typically use Git. It is an open-source tool that allows you to keep track of all the different changes that happened in all of the files inside the main folder.
The Git Terminology
The main folder where Git is set up is called a repository. Inside the repository, you should see all of the files that you have saved or created. Now let us say you want to create a new file and add it to Git. You simply create the file with the necessary content, and now you have created or modified a file. Next, you add it to the staging area. When a file is in staging, it means that the file is complete and ready to be added to Git. Finally, once you are ready, you can commit the changes. Committing tells Git to start keeping track of the staged files.
From then on, when you view the commit history of that Git repository, you will see a commit that contains the newly created file.
The same concept applies to editing files. They go through the same process - modification, staging, and committing. If you go through the history and see that commit, you can see how the file looked like before the changes.
Commit Hash
When you commit changes to the Git repository, it creates a hash for that commit. A hash is basically a bunch of numbers and letters that are created based on specific values (if you want to learn more about hashes, check out this article about hashing and encryption).
Each commit in the history of a Git repository is indicated by a commit hash. This commit hash allows you to put a unique ID to each commit. Say you have multiple versions of a system, from Version 1 to Version 30. And a user asks you for a specific version (e.g. 13). You can easily find that specific version because you already have the ID of the specific commit this version is on. In Git, it is the same concept, except with hashes to make it even more unique.
Branches
Now let us say you are working on two different features, Login and the Dashboard. You would not put them all under one commit, and the reason for that is it becomes confusing when you want to search for a specific change. A typical commit would contain tens of files, making it difficult to view the exact things you are looking for.
Branches are just like the ones you see on a tree. Trees have different branches coming from the main root, and it branch has different leaves on it. Branches in Git are very similar. You start with the root branch, often referred to as the master or the main branch. It typically contains all the completed and tested codes. From there, more branches can be made to contain their specific changes.
Let us say you want to start working on the Login feature. You would branch out from the main branch to a new one which you might call the login_feature. Here, you would work on and commit all the changes related to this specific feature. Once you are done and all the codes are tested properly. Then from here, you can merge the login_feature branch to the main branch. Merging tells the other branch you wish to merge TO that there are commits I would like to add to your branch.
The main branch contains commit numbers 1 and 2. While the new branch login_feature contains commit numbers 3 and 4. If you merge the new branch to the main branch, the main branch will now have the commit numbers 1, 2, 3, and 4.
Practical Example
In this example, we will create our very own git repository, make a commit, branch out into a new branch and make a commit there, then merge that branch to the main branch we have.
Prerequisites
Git can be installed on almost all major Operating Systems, including Windows, Mac OS, and Linux. So all you need to have is a laptop or PC that has internet access.
But for the sake of the tutorial, I will be including additional commands, such as ones for creating files, based on the Linux operating system. Some commands might be different for you, depending on where you are doing the implementation.
Installation
To start, you would need to install Git. The installation process will depend on your Operating System, but you can check out the official website’s methods for downloading on each of the major Operating Systems:
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
Once the installation is completed, you can make sure it was installed properly by accessing the command line and typing git version. This should print out the installed version of git you have on your device.
Set up
To start using Git, we will first need to create the main folder where the git repository and associated files will be contained in. To do that, run:
mkdir testing_git
cd testing_git
This creates a folder titled testing_git and accesses it.
Once you have created a folder, we can go ahead and create the repository. We can do that by running:
git init
Along with the repository, it has created the first branch titled master, which is the default name for the first git branch.
Now we can add our first file.
Adding and Committing
Now that we have a repository, we can create our first file, and add some content to it. We can do that by running:
touch first.txt
echo "Version 1" > first.txt
We added the phrase Version 1 to the file, as shown above so that we can check it out later.
We are ready to add this file to the staging area. Run the below command to do that:
git add first.txt
We can make sure it was added to the staging area by running:
git status
This will show an output that has the new and edited files, like so:
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: first.txt
Now we can finally commit our file and make it final. We can do that by running:
git commit -m "First File. Version 1"
This command commits the changes and adds the message First File. Version 1. Commit messages are important because they make it easy knowing what changes were made to the application, without necessarily going through the codes. So it is important to write it as a summary of what the changes are made for.
We can check out the history of the commits made by running:
git log
This will display information like the commit hash, author name, date, and the commit message.
Now that we created our first commit, let us create a new branch and make some changes to that branch.
Creating a New Branch
We can create a new branch titled version_2 by running:
git branch version_2
We now need to move to the new branch, so that any new commits that will be made, will be made on this new branch:
git checkout version_2
We can make sure we are on the correct branch by running:
git branch
You will see an output that includes a star beside the name of the current branch:
master
* version_2
We can now start making changes to the file and committing it:
echo "Version 2" > first.txt
git add first.txt
git commit -m "updated to version 2"
Now, if we check the commit history, we will see the first one we created while on the master branch and the new one we just made.
The reason we see the previous commit we made (Version 1) is that we created the new branch from the master branch. This means that the new branch has the same files and the same commits as the original branch.
Finally, let us merge the new branch to the master branch.
Merging The New Branch
Now that we are satisfied with the changes in the new branch, we can merge it to the master branch. To do that, we first need to checkout to the master branch:
git checkout master
Then, we will merge the version_2 branch to our current branch (the master) by running:
git merge version_2
It will display a message that the first.txt file has been updated. To make sure the change happened, we can look at the file:
hazem@laptop ~/D/git_article (master)> cat first.txt
Version 2
And finally, to make sure it was added to the master branch, we can look at the commit history:
git log
The latest commit at the top will be the commit you made on the version_2 branch, with the message updated to version 2.
That is it!
Conclusion
We went through what a Version Control System is, what is Git and its terminology, as well as a full tutorial on how to use it, which included creating the repository, adding and committing a file, creating a new branch, and merging the new branch to the main one.
I hope you learned about Git and understood how useful it is. Git is a very popular tool used by millions of developers across the world. It is a fundamental technology that every developer needs to understand, at least to a certain extent.
Thank you for reading and see you in the next one!