15. Advanced Git Features
At the heart of Git are the repositories. Chapters 13 and 14 introduced you to tools that enabled you to work with the local repository. In this chapter you learn how to interact with the central repository server.
Managing Repositories
From your perspective, the central repository server is also considered the remote repository as opposed to the repository that is on your system (the local repository).
To see the location of your remote repository, execute the git remote -v command:
ocs@ubuntu:~/ocs$ git remote -v
origin https://gitlab.com/borothwell/ocs.git (fetch)
origin https://gitlab.com/borothwell/ocs.git (push)
Both lines point to the same location. The first line refers to the process of downloading content from the remote repository and the second line refers to the process of uploading content to the remote repository.
Very likely you will be working on separate projects, each with its own remote repository. To access another project, execute the git remote add command:1
ocs@ubuntu:~/ocs$ git remote add docs
➥ https://gitlab.com/borothwell/docs.git
ocs@ubuntu:~/ocs$ git remote -v
docs https://gitlab.com/borothwell/docs.git (fetch)
docs https://gitlab.com/borothwell/docs.git (push)
origin https://gitlab.com/borothwell/ocs.git (fetch)
origin https://gitlab.com/borothwell/ocs.git (push)
The docs argument is how you want to refer to this remote repository locally. The last argument is the URL path to the remote repository.
Of course, after you have added the remote repository, you should also clone it using the git clone command:
ocs@ubuntu:~/ocs$ cd ..
ocs@ubuntu:~$ git clone https://gitlab.com/borothwell/docs.git
Cloning into 'docs'...
Username for 'https://gitlab.com': borothwell
Password for 'https://[email protected]':
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
ocs@ubuntu:~$ ls
docs ocs
ocs@ubuntu:~$ ls -a docs
. .. .git
Even though this is an empty repository, you can see that it has been cloned by the fact it created a ~/docs directory and a docs/.git directory. To perform work in this project, simply create files in the ~/docs directory and execute the git commands while in this directory.
Getting Content from the Remote Server
The process of getting the content from the remote server to the local repository and working directory is fairly simple. In this situation, you execute the git clone command to duplicate everything in the project from the remote server to the local system.
However, this process can become much more complex later in the development cycle when you want to include changes from the remote server (likely from other developers) to your local repository and working directory. You can use several different methods, each with a different intended result.
Before getting into the process of getting content from the remote server, visualizing how content is sent from the working directory to other locations might be helpful. Look at Figure 15.1 for a demonstration.
Figure 15.1 Git commands to send changes from the working directory
In Figure 15.1 you can see the flow of version changes. The git add command sends the working version to the staged area. The git commit command sends the staged version to the local repository. The git commit -a command can send a version from the working directory to the staged area and then to the local repository. Lastly, the git push command sends the changed versions of the files to the remote repository.2
When to Commit versus When to Push
I am often asked when to use git commit versus git push. Some organizations provide rules or guidelines for when a developer should use commit versus push. If your organization doesn’t have any guidelines, I suggest using the following guidelines
Commit often! It is the means by which you can undo a mistake or go back to an older version. Think of it like a “save as” of a document.
Push when you have something to share to other developers. Pushing multiple times a day for subtle file changes makes the process of merging and applying changes much more difficult.
File versions cannot only be sent from the working directory up to the remote repository, but they can also be propagated from the remote repository to the local repository and the working directory. See Figure 15.2 for a visual description of the commands that can perform these actions.3
Figure 15.2 Git commands to retrieve changes from the remote repository
Details regarding these commands:
The git fetch command downloads the latest version history of files from the remote repository to the local repository. This command does not change your working directory, but you can use the git checkout command to make the working directory contain the latest versions of the files of the branch.
The git fetch command only downloads the file versions. It does not perform any merging.
The git pull command downloads the latest version history of files from the remote repository to the local repository, but this command also performs a merge operation and updates the content of your working directory. The merging process is the same as that described in Chapter 14.
The git rebase command takes all the changes from a branch and applies them to the current branch. This is a process called patching, which is described in more detail later in this chapter.
Connecting via SSH
The default (and recommended) method of communication with the remote repository is HTTPS. Another method that can be used is SSH. Both methods should provide a secure (and encrypted) communication method. Typically, HTTPS is recommended for a few reasons:
No additional setup is required when you use HTTPS. If you choose to use SSH, then you must generate a SSH key and upload it to the remote repository.
When using HTTPS, Git makes use of a feature called credential helper automatically to cache your password. This means when you connect to the remote repository, you won’t have to provide your password each time. This could also be configured for SSH, but it isn’t done so automatically (you need to configure this using a SSH feature called ssh-agent).
The third possible reason is related to firewalls. In networks that are highly secured with strict firewalls, the HTTPS network port is more likely to be “open” than the SSH network port.
This doesn’t mean you shouldn’t use SSH, just that the developers of Git recommend HTTPS. If you do want to use SSH, then you first need to execute the following command:
ocs@ubuntu:~/ocs$ ssh-keygen -t rsa
This creates an SSH key in the ~/.ssh/id_rsa.pub file. You must upload this file to the SSH server, which you normally do via the web interface. See Figure 15.3 for an example of this interface on gitlab.com.
After uploading the SSH keys to the remote repository server, you can have the git command use SSH instead of HTTP by using the following syntax:
git clone ssh://user@server/project.git
Another method that is popular is to use the following syntax:
git clone user@server:project.git
Patching
The idea of patching is that you will discover situations in which it won’t be easy to perform a simple merge between two different branches. Several reasons exist as to why this might be, including the following:
When you want to implement changes from a branch that hasn’t been made available on the central repository
When you want to implement changes from a specific version of a file
Actually several different techniques can be utilized to perform patching. The most basic (and common) method is to use the git diff command that was discussed in Chapter 14 to generate a diff file. You do this by executing the git diff command and redirecting the output to a file. For example:
git diff A B > file.patch
This patch file will be used to modify an existing checked-out file to include the differences. This is performed by using the git apply command. For example:
git apply file.patch
Often the patch file is generated on one system and then copied to another system before applying. It is also typically a good idea to use the --check option to test the patch before actually applying it:
git apply --check file.patch
git apply file.patch
Summary
In this chapter you learned how to manage repositories. You also learned how to change the method of connecting to a remote repository from HTTPS to SSH. Last, you were introduced to the concept of patching in Git.
1 I created this new project by using the web interface provided by gitlab.com.
2 None of these commands are new because they were covered in previous chapters. However, visualizing this process can help you understand the next topic better.
3 Note that the git clone command is not included in Figure 15.2. This is because typically you only run this command once when you first download the remote repository.