“This is the second day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021”
Git is a distributed version control system, typically used for software source code versions. The version control system keeps track of different versions of source files in the repository. Distributed version control systems track sources across multiple repositories. Thus, John and Mary can each have their own repository containing source code for the same project, and then extract updates from each other’s repositories. If that sounds complicated, don’t worry. All of this will be explained in this Git tutorial.
Git was originally developed by Linus Torvalds, the smart guy who brought us Linux. Linus was not satisfied with the existing version control system, so he started developing something different. Meet the needs of a very distributed team of Linux kernel developers.
Today, Git is so popular that many open source codes are hosted in Git repositories on GitHub, BitBucket, and Google code. These are services that host version control repositories for developers.
Install Git
The official Git implementation is a command-line tool. To use Git, you must first install it. You can install Git on your machine in several ways. If you prefer a command line interface, go to the official Git site and download and install Git:
Atlassian SourceTree
If you prefer a graphical user interface, then I recommend using Atlassian’s SourceTree. This is an easy-to-use graphical Git client that can connect to both local and remote (hosted) Git repositories, including GitHub and BitBucket. SourceTree is also popular. In this tutorial, I will demonstrate how to use Git using SourceTree. You can get Atlassian SourceTree here: www.sourcetreeapp.com
This tutorial uses SourceTree V. 1.6.12.0. If you are using a different version of SourceTree, the GUI may look slightly different from the screenshots I show here, but the basic principles are the same.
Git is the Core concept
Before I show you how to use Git, I’ll first explain the core concepts of Git and how you use it most often. Once you understand this, it will be easier to drill down into the many different Git commands available.
Git repository
Git revolves around the concept of a repository. A repository is a database that keeps track of all versions of source code added to it. Repositories are stored on your local disk, but can also be stored on a remote server. Here’s an illustration of a Git repository:
Git repositories usually contain source code for a single project. However, you can keep multiple projects in a single Git repository, or split large projects into multiple Git repositories. Exactly how you organize your code into the repository is up to you. To start, just start with one Git repository per project, and if the project grows, split the individual subprojects into their own repositories.
All developers working on the same project have their own Git repository for that project on their local disk. This means that every developer has a copy of the project code in their Git repository. These Git repositories may even contain different versions of project files (to some extent), with developers working on different parts of the project. The following is an example of this situation. One developer makes changes to file B, while the other makes changes to file A, both in their own copy of the project (in their own repository).
Extract changes from other repositories
Once a developer completes a feature, other developers can pull that feature into their own Git repository to create the latest version of the entire software project. This is an example of a Git pull operation. Developer 1 (left) extracts the changes from Developer 2’s repository (right).
After pulling, the developer who pulled gets the latest changes from the repository he or she extracted. In the previous case, developer 1’s repository looks like this after developer 1 extracts from Developer 2’s repository:
As you can see, Developer 1 now has the latest version of file A that was changed by Developer 2.
The pull operation is one-way. In the above case, developer 1 extracts the changes from developer 2’s repository, but Developer 2 does not receive any changes from Developer 1. To update both repositories to the latest version of all files, both developers must extract from each other’s repositories.
The fact that every developer has his or her own repository and copy of code, which may even be slightly different from all other developers’ copies, is what makes Git distributed. This code is not kept in a central “master” repository, but is distributed across many repositories.
Use the publication repository
It is not uncommon for projects to create a “release repository” where finished features are pushed to where all developers can get finished versions of the latest features. This publication repository then works as a Facto main repository.
Having a release repository makes it easier for developers to keep their repositories up to date with changes from other developers. Developers only need to extract changes from the release repository, not from all the other developers on the team. This way, developers can get the latest updates and only get them when the update is actually running, such as “ready for release.” Here are two examples of developers using the release repository to coordinate updates:
Create a Git repository
Now that you’ve seen the core concepts, let’s get started with Git. To use Git, the first thing you need to do is create a Git repository. This is calling “initialization” of the Git repository. You do this using the Git init command. I’ll show you how to start Git with my favorite Git client, Atlassian SourceTree.
In the upper left corner of SourceTree, you will find the Clone/New button. Click this button to create a new Git repository. Here is a screenshot of SourceTree’s clone/New button:
When you click the Clone/New button, the following dialog opens:
In the Target Path field of the dialog box, type the path to the location of your Git repository on your local disk. You can also click… Button to navigate to the directory where you want to create your Git repository.
When you are in the target path of your Git repository, click the Create button. SourceTree will now create the Git repository for you. When a Git repository is created, SourceTree will display the new Git repository on the left side of the screen, as shown in the SourceTree screenshot below:
Git repository workspace
Git repositories have a workspace. A workspace is where the working versions of files in a project are stored. The workspace is in the same directory where you created your Git repository. That is, include.git subdirectories in the same directory.
When you “commit” a file to the repository, a copy of the working version is inserted into the Git repository (.git subdirectory). The repository will keep track of many different versions of the files you commit. The workspace will always contain only the latest version of the file, but the repository (the.git directory) will also contain all previously committed versions.
Workspaces can contain subdirectories, but do not put any of your files or directories into a.git directory. This directory is reserved for Git. As a general rule, you shouldn’t mess around in a.git directory unless you know exactly what you’re doing. You may be corrupting your Git repository.
Commit files to a Git repository
Once the Git repository is created, the next step is to commit the files to the repository. You usually: commit a new file, or commit a new version of an existing file, or delete the file to the repository.
- Commit the new file to the repository.
- Commit the new version of the added file to the repository.
- Delete files to the repository.
Each of these actions is described in the following sections.
Commit the new file to the Git repository
First, you need to create a file in the repository workspace. In the example shown later, I create a file called file-1.txt for my workspace with the text “This is version 1” inside.
The files you create in your workspace are divided into two groups:
- Unstaged file
- Staged file
When you first create a file in a repository workspace, the file is non-hierarchical. When you commit your workspace to the repository, only staged files are included in the commit. To commit a file, you must first add it to the staged file set. In SourceTree, you do this on the right side of the GUI. Here is a screenshot showing the unstaged file file-1.txt in the SourceTree GUI’s non-staged file area:
You can add a file to a staged file group in SourceTree by clicking the check box to the left of the file name. Here’s what the SourceTree GUI looks like after adding file-1.txt to a staged file group:
You can now submit file-1.txt to the repository by clicking the “Submit” button in the upper left corner of the SourceTree GUI. Here is a screenshot of the “Submit” button:
When you click the “Submit” button, a small dialog box opens in the lower right corner of the SourceTree GUI. In this dialog, you can type a text that describes the changes you have made to the submitted file. This description will be useful later when you look at the commit history to see what changes were made to the file.
In this case, I just type “first version added” in the Submit dialog box, and then click the submit button at the bottom of the dialog box (instead of the Submit button at the top left corner of the GUI that you click to open the Submit dialog). Before I click submit, this screenshot shows the SourceTree GUI:
The screenshot below shows how SourceTree handles the submission. Now SourceTree says there is nothing left to promise. This is because all staged files have been committed and there are no non-staged files.
Commit the new version of the file to the Git repository
You usually make changes to files after they are first added to a Git repository. Once you have a new, stable version of a file, you may want to commit that version to a Git repository.
In SourceTree, this process is very similar to the one used when adding files for the first time. To demonstrate how to add a new version of the file, I change the text in ‘file-1.txt’ to ‘This is version 2’. After the changes are saved to ‘file-1.txt’, the SourceTree application takes a little time to update the GUI. After the update, the right side of the SourceTree GUI now looks like this:
file-1.txtAgain in the unstaged file area.
To submit the new version of file-1.txt, click the check box next to the file name of the unstaged area. This will add the files to the staged file set. After you add a file to a staged file set, you commit the file the same way you did when you first added the file.
Commit multiple files at once
Ideally, each commit to the repository should represent a fully coherent, functional version of all the files in the project. Imagine if the file you submitted contains a compilation error because it depends on a new version of another file you haven’t submitted yet. This will prevent developers who take your submitted files out of the repository from doing their work, since the project will not compile now. We want to avoid that.
To ensure that your commit keeps the project in a coherent functional state, you may sometimes need to commit multiple files in the same commit operation. It’s easy to do that. Simply add all the files to be committed from the non-staged fileset to the staged fileset and commit the file. This process is like submitting a single file.
Delete files from Git repository
Sometimes, you may also need to delete files from your project. These files then need to be removed from your project’s Git repository.
To delete a file from your project, simply delete the file from your repository workspace. After deleting files from the workspace, SourceTree scans the workspace and detects that the files have been deleted. The file will then show up as deleted in the unstaged file area. Here’s a screenshot of what it looks like:
To delete files from the repository, add the deleted files to the staged file set, and then click Submit. Committing the rest of the deletion process is similar to submitting a new file or a new version of a file. Type a description of the changes you want to commit to the repository, and then click the Submit button under the Submit dialog box. The file is now deleted.