- Version Control Concepts
- Installing Git
- Git Concepts and Features
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Git Concepts and Features
One of the challenges to using Git is just understanding the concepts behind it. If you don’t understand the concepts, then all the commands just seem like some sort of black magic. This section focuses on the critical Git concepts as well as introduces you to some of the basic commands.
Git Stages
It is very important to remember that you “check out”3 an entire project and that most of the work you do will be local to the system that you are working on. The files that you check out will be placed in a directory under your home directory.
To get a copy of a project from a Git repository, you use a process called cloning. Cloning doesn’t just create a copy of all the files from the repository; it actually performs three primary functions:
Creates a local repository of the project under the project_name/.git directory in your home directory. The files of the project in this location are considered to be “checked out” from the central repository.
Creates a directory where you can directly see the files. This is called the working area. Changes made in the working area are not immediately version controlled.
Creates a staging area. The staging area is designed to store changes to files before you commit them to the local repository.
This means that if you were to clone a project called Jacumba, the entire project would be stored in the Jacumba/.git directory under your home directory. You should not attempt to modify these directly. Instead, look directly in the ~/Jacumba directory and you will see the files from the project. These are the files that you should change.
Suppose you made a change to a file, but you have to work on some other files before you were ready to commit changes to the local repository. In that case, you would stage the file that you have finished working on. This would prepare it to be committed to the local repository.
After you make all changes and stage all files, then you commit them to the local repository. See Figure 12.6 for a visual demonstration of this process.
)
Figure 12.6 Git stages
Realize that committing the staged files only sends them to the local repository. This means that only you have access to the changes that have been made. The process of “checking in” the new versions to the central repository is called a push.
I explain each of these steps in greater detail later. Consider this to be an introduction to the concepts that will help you understand the process better when I introduce the Git commands.
Choosing Your Git Repository Host
First, the good news: Many organizations provide Git hosting—at the time of this writing, more than two dozen choices. This means you have many options to choose from. That’s the good news…and the bad news.
It is only bad news because it means you really need to spend some time researching the pros and cons of the different hosting organizations. For example, most don’t charge for basic hosting but do charge for large-scale projects. Some only provide public repositories (anyone can see your repository) whereas others allow you to create private repositories. There are many other features to consider.
One of the features that might be high on your list is a web interface. Although you can do just about all repository operations locally on your system, being able to perform some operations via a web interface can be very useful. Explore the interface that is provided before making your choice.
Configuring Git
Now that you have gotten through all the theory,4 it is time to actually do something with Git. This next section assumes the following:
You have installed the git or git-all software package on your system.
You have created an account on a Git hosting service.
The first thing you want to do is perform some basic setup. Whenever you perform a commit operation, your name and email address will be included in the metadata. To set this information, execute the following commands:
ocs@ubuntu:~$ git config --global user.name "Bo Rothwell" ocs@ubuntu:~$ git config --global user.email "bo@onecoursesource.com"
Obviously you will replace "Bo Rothwell" with your name and "bo@OneCourseSource.com" with your email address. The next step is to clone your project from the Git hosting service. Note that before cloning, only one file is in the user's home directory:
ocs@ubuntu:~$ ls first.sh
The following cloned a project named ocs:
ocs@ubuntu:~$ git clone https://gitlab.com/borothwell/ocs.gi Cloning into 'ocs'... Username for 'https://gitlab.com': borothwell Password for 'https://borothwell@gitlab.com': remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. Checking connectivity... done.
After successful execution, notice a new directory in the user’s home directory:
ocs@ubuntu:~$ ls first.sh ocs
If you switch to the new directory, you can see what was cloned from the repository (only one file so far exists in the repository):
ocs@ubuntu:~$ cd ocs ocs@ubuntu:~/ocs$ ls README.md
Next, create a new file in the repository directory. You can either create one from scratch or copy a file from another location:
ocs@ubuntu:~/ocs$ cp ../first.sh
Remember, anything placed in this directory is not version controlled because this is the working directory. To put it in the local repository, you first have to add it to the staging area and then you need to commit it to the repository:
ocs@ubuntu:~/ocs$ git add first.sh ocs@ubuntu:~/ocs$ git commit -m "added first.sh" [master 3b36054] added first.sh 1 file changed, 5 insertions(+) create mode 100644 first.sh
The git add command places the file in the staging area. The git commit command takes all the new files in the staging area and commits them to the local repository. You use the -m option to add a message; in this case the reason for the commit was given.
It is important to highlight that no changes have been made to the repository on the server. The git commit command only updates the local repository. You can see that the server repository has not been modified by looking at Figure 12.7, which shows a screenshot of the web-based interface of the current project. Notice that the original file, README.md, was pushed to the server several days ago, but the new file, first.sh, does not have an entry.
)
Figure 12.7 Server repository is unchanged after executing the git commit command
Most likely you would make additional changes to your local project and then "check in" (push) the changes to the server’s repository:
ocs@ubuntu:~/ocs$ git push -u origin master Username for 'https://gitlab.com': borothwell Password for 'https://borothwell@gitlab.com': Counting objects: 4, done. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 370 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://gitlab.com/borothwell/ocs.git 12424f5..3b36054 master -> master Branch master set up to track remote branch master from origin.
See Figure 12.8 to verify the push was successful.
)
Figure 12.8 Server repository is changed after executing the git push command
At this point all changes of the files from the staging area have been updated to the local repository and the central server repository.