If you have been using GNU/Linux for any amount of time chances are pretty good that you have heard of git. You may be wondering, what exactly is git and how do I use it? Git is the brainchild of Linus Torvalds, who developed it as source code management system during his work on the Linux kernel.
Since then it has been adopted by many software projects and developers due to its track record of speed and efficiency along with its ease of use. Git has also gained popularity with writers of all kinds, since it can be used to track changes in any set of files, not just code.
In this tutorial you will learn:
- What is Git
- How to install Git on GNU/Linux
- How to Configure Git
- How to use git to create a new project
- How to clone, commit, merge, push and branch using the git command
Software Requirements and Conventions Used
|Requirements, Conventions or Software Version Used
|Any GNU/Linux Operating System
|Privileged access to your Linux system as root or via the
# – requires given linux commands to be executed with root privileges either directly as a root user or by use of
$ – requires given linux commands to be executed as a regular non-privileged user
What is Git?
So what is git? Git is a specific implementation of version control known as a distributed revision control system which tracks changes over time to a set of files. Git enables both local and collaborative history tracking. The benefit of collaborative history tracking is that it documents not just the change itself but the who, what, when, and why behind the change. When collaborating, changes made by different contributors can later be merged back into a unified body of work.
What is a distributed revision control system?
So what is a distributed revision control system? Distributed revision control systems are not based on a central server; every computer has a full repository of the content stored locally. A major benefit of this is that there is no single point of failure. A server can be used to collaborate with other individuals, but if something unexpected were to happen to it, everyone has a backup of the data stored locally (since git is not dependent on that server), and it could easily be restored to a new server.
Who is git for?
I want to emphasize that git can be used entirely locally by an individual without ever needing to connect to a server or collaborate with others, but it makes it easy to do so when necessary. You might be thinking something along the lines of “Wow, that sounds like a lot of complexity. It must be really complicated getting started with git.”. Well, you would be wrong!
Git has a focus on processing local content. As a beginner you can safely ignore all of the networked capabilities for now. First we look at how you can use git to track your own personal projects on your local computer then we will look at an example of how to use git’s network functionality and finally we will see an example of branching.
Installing git on Gnu/Linux is as simple as using your package manager on the command line as you would to install any other package. Here are a few examples of how this would be done on some popular distributions.
On Debian and Debian based systems such as Ubuntu use apt.
$ sudo apt-get install git
On Redhat Enterprise Linux and Redhat based systems such as Fedora use yum.
$ sudo yum install git
(note: on Fedora version 22 or later replace yum with dnf)
$ sudo dnf install git
On Arch Linux use pacman
$ sudo pacman -S git
Now git is installed on our system and in order to use it, we just need to get some basic configuration out of the way. The first thing you will have to do is configure your e-mail and username in git. Note that these are not used to login to any service; they are simply used to document what changes were made by you when recording commits.
In order to configure your e-mail and username enter the following commands into your terminal, substituting your e-mail and name as values between the quotation marks.
$ git config --global user.email "email@example.com" $ git config --global user.name "your username"
If necessary, these two pieces of information can be changed at any time by reissuing the above commands with different values. If you choose to do this then git will change your name and e-mail address for historical records of commits going forward, but will not change them in previous commits, so it is recommended that you ensure that there are no errors initially.
In order to verify your username and e-mail enter the following:
$ git config -l
Creating Your First Git Project
To setup a git project for the first time it must be initialized using the following command:
$ git init projectname
A directory is created in your current working directory using the given project name. This will contain the project files/folders (source code or your other primary content, often called the working tree) along with the control files used for history tracking. Git stores these control files in a
.git hidden subdirectory.
When working with git, you should make the newly created project folder your current working directory:
$ cd projectname
Let’s use the touch command to create an empty file which we will to use to create a simple hello world program.
$ touch helloworld.c
To prepare the files in the directory to be committed to the version control system we use git add. This is a process known as staging. Note, we can use
. to add all files in the directory, but if we only want to add select files or a single file then we would replace
. with the desired filename(s) as you will see in the next example.
$ git add .
Don’t Be Afraid To Commit
A commit is performed in order to create a permanent historical record of exactly how project files exist at this point in time. We perform a commit using the
-m flag to create a historical message for the sake of clarity.
This message would typically describe what changes were made or what event occurred to make us want to perform the commit at this time. The state of the content at the time of this commit (in this case, the blank “hello world” file we just created) can be revisited later. We will look at how to do that next.
$ git commit -m "First commit of project, just an empty file"
Now let’s go ahead and create some source code in that empty file. Using your text editor of choice enter the following (or copy and paste it) into the helloworld.c file and save it.
Now that we have updated our project, let’s go ahead and perform git add and git commit again
$ git add helloworld.c $ git commit -m "added source code to helloworld.c"
Now that we have two commits in our project we can begin to see how it can be useful to have a historical record of the changes in our project over time. Go ahead and enter the following into your terminal to see an overview of this history so far.
$ git log
You will notice that each commit is organized by it’s own unique SHA-1 hash id and that the author, date, and commit comment are presented for each commit. You will also notice that the latest commit is referred to as the
HEAD in the output.
HEAD is our current position in the project.
To view what changes were made in a given commit, simply issue the git show command with the hash id as an argument. In our example, we will enter:
$ git show 6a9eb6c2d75b78febd03322a9435ac75c3bc278e
Which produces the following output.
Now, what if we want to revert back to the state of our project during a previous commit, essentially completely undoing the changes that we have made as if they had never happened?
To undo the changes we made in our previous example, it is as simple as changing the
HEAD using the
git reset command using the commit id that we want to revert to as an argument. The
--hard tells git that we want to reset the commit itself, the staging area (files we were preparing to commit using git add) and the working tree (the local files as they appear in the project folder on our drive).
$ git reset --hard 220e44bb924529c1f0bd4fe1b5b82b34b969cca7
After performing this last command, examining the content of the
file will reveal that it has returned to the exact state it was in during our first commit; a blank file.
Go ahead and enter git log into the terminal again. You will now see our first commit, but not our second commit. This is because git log only shows the current commit and all of it’s parent commits. In order to see the second commit we made enter git reflog. Git reflog displays references to all changes that we have made.
If we decided that resetting to the first commit was a mistake then we could use the SHA-1 hash id of our second commit as displayed in the git reflog output in order to reset back to our second commit. This would essentially redo what we had just undone and would result in us getting the content back in our file.
Working With a Remote Repository
Now that we have gone over the basics of working with git locally we can examine how the workflow differs when you are working on a project that is hosted on a server. The project may be hosted on a private git server owned by an organization with whom you are working or it may be hosted on a third party online repository hosting service such as GitHub.
For the purpose of this tutorial let’s assume you have access to a GitHub repository and you want to update a project you are hosting there.
First, we need to clone the repository locally using the git clone command with the URL of the project and make the cloned project’s directory our current working directory.
$ git clone project.url/projectname.git $ cd projectname
Next, we edit the local files, implementing the changes that we desire. After editing the local files we add them to the staging area and perform a commit just like in our previous example.
$ git add . $ git commit -m "implementing my changes to the project"
Next, we have to push the changes that we made locally to the git server. The following command will require you to authenticate with your credentials to the remote server (in this case, your GitHub username and password) before pushing your changes.
Note that changes pushed to the commit logs in this manner will use the e-mail and username that we specified when first configuring git.
$ git push
Now you should feel comfortable installing git, configuring it and using it to work with both local and remote repositories. You have the working knowledge to join the ever-growing community of people who harness the power and efficiency of git as a distributed revision control system. Whatever you may be working on, I hope that this information changes the way that you think about your workflow for the better.