Chapter 2
Getting Started
You can try out Git right away if you’d like. This chapter describes how to set up your first project. It shows commands for versioning changes, viewing the history and exchanging versions with other developers.
Setting up Git
First you need to install Git. You will find everything you need on the Git website:
http://git-scm.com/download
Git is highly configurable. To start, it is sufficient to submit your user name and e-mail address with the config command.
> git config --global user.email "[email protected]"
Your First Git Project
It is best if you use a separate project to test Git. Start with a simple small project. Our example shows a tiny project called first-steps with two text files.
Figure 2.1: Our sample project
Make a copy before you play with the example in your pet project! It is not so easy in Git to permanently delete or break something, and Git usually Git warns you if you are going to do something “dangerous.” Nevertheless, it is better to take precautions.
Creating a repository
First, you need to create a repository in which the history of the project will be stored. You do this by using the init command in the project directory. A project directory with a repository is called a workspace.
> cd /projects/first-steps > git init Initialized empty Git repository in /projects/first-steps/.git/
The init command above created a repository located in a hidden directory named .git. Be warned that the directory may not show in Windows Explorer or Mac Finder.
Figure 2.2: The directory where the repository is located
Your First Commit
Next, you are going to add foo.txt and bar.txt files to the repository. In Git, a project version is called a commit, and is achieved in two steps. First, use the add command to determine which files should be included in the next commit. Second, use the commit command to transmit the changes to the repository and assign a commit hash that identifies the new commit. Here the hash is 2f43cd0, but yours might be different, depending on the contents of your files.
> git add foo.txt bar.txt > git commit --message "Sample project imported." master (root-commit) 2f43cd0] Sample project imported. 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 bar.txt create mode 100644 foo.txt
Checking the Status
Now change the content of the foo.txt file, delete the bar.txt file, and add a new file named bar.html. The status command shows all changes since the last commit. Note that the new file bar.html is shown as untracked, because it has not been registered using the add command.
> git status # On branch master # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in # working directory) # # deleted: bar.txt # modified: foo.txt # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # bar.html no changes added to commit (use "git add" and/or "git commit -a")
Figure 2.3: Diff representation in graphical tool (kdiff3)
If you want to see more details, use the diff command to display each modified row. Many people find the output of diff difficult to read. Fortunately, there are a whole range of tools and development environments that can show the changes more clearly (See Figure 2.3).
> git diff foo.txt diff --git a/foo.txt b/foo.txt index 1910281..090387f 100644 --- a/foo.txt +++ b/foo.txt @@ -1 +1 @@ -foo No newline at end of file +foo foo No newline at end of file
Committing after Changes
All changes must be reported to every new commit. Use the add command for modified and new files and use the rm command for deleted files.
> git add foo.txt bar.html > git rm bar.txt rm 'bar.txt'
Calling the status command again shows what will be included in the next commit.
> git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: bar.html # deleted: bar.txt # modified: foo.txt #
Use the commit command to commit these changes.
> git commit --message "Some changes." [master 7ac0f38] Some changes. 3 files changed, 2 insertions(+), 2 deletions(-) create mode 100644 bar.html delete mode 100644 bar.txt
Displaying the History
The log command displays the project history. All commits are shown in chronologically descending order.
> git log commit 7ac0f38f575a60940ec93c98de11966d784e9e4f Author: Rene Preissel <[email protected]> Date: Thu Dec 2 09:52:25 2010 +0100 Some changes. commit 2f43cd047baadc1b52a8367b7cad2cb63bca05b7 Author: Rene Preissel <[email protected]> Date: Thu Dec 2 09:44:24 2010 +0100 Sample project imported.
Collaboration with Git
You now have a workspace with project files and a repository with a history of the project. In a classic centralized version system, such as CVS and Subversion, each developer has his/her own workspace, but all developers share a common repository. In Git, each developer has his/her own workspace with a separate repository, hence a full-fledged version control system that does not rely on a central server. Developers working together on a project can exchange commits in their repositories. To test this, let’s create a new workspace that simulates the activities of a second developer.
Cloning A Repository
The new developer needs his/her own copy (called a clone) of the repository. It contains all the information that includes the original and the entire project history. Run this clone command to make a clone.
> git clone /projects/first-steps /projects/first-steps-clone Cloning into first-steps-clone... done.
The project structure will look like the one in Figure 2.4.
Figure 2.4: The sample project and its clone
Getting Changes from Another Repository
Modify the first-steps/foo.txt file and then do the following to create a new commit.
> cd /projects/first-steps > git add foo.txt > git commit --message "A change in the original."
The new commit is now stored in the original first-steps repository, but is still missing from the clone (first-steps-clone) repository. To better understand the situation, we are showing the log for first-steps:
> git log --oneline a662055 A change in the original. 7ac0f38 Some changes. 2f43cd0 Sample project imported.
In the next step, modify the first-steps-clone/bar.html file in the clone repository and then do the following.
> cd /projects/first-steps-clone > git add bar.html > git commit --message "A change in the clone." > git log --oneline 1fcc06a A change in the clone. 7ac0f38 Some changes. 2f43cd0 Sample project imported.
You now have a new commit in each of the two repositories. Next, we will transfer the new commit in the original repository to the clone using the pull command. When we created the clone repository, the path to the original repository was also stored in the clone, so a pull command would know where to pick up new commits.
> cd /projects/first-steps-clone > git pull remote: Counting objects: 5, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /projects/first-steps 7ac0f38..a662055 master -> origin/master Merge made by recursive. foo.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
The pull command has picked up the new changes from the original repository, compared them with local changes in the clone and merged both changes in the workspace and created a new commit it. This is called a merge.
Attention! In some cases there will be conflicts when merging. In such an event, Git cannot automatically merge the versions. In this case, you need to manually clean up the files first and then confirm the changes with a commit.
A new log command displays the result of the merge after the pull. This time we use a graphical version of the log.
> git log --graph 9e7d7b9 Merge branch ’master’ of /projects/first-steps * | | * a662055 A change in the original. * | 1fcc06a A change in the clone. |/ * 7ac0f38 Some changes. * 2f43cd0 Sample project imported.
The history is no longer linear. In the graph you can see very clearly the parallel development (the two commits in the middle) and then the merge commit with which the branches were merged again (at the top).
Picking up Changes from Any Repository
Used without a parameter, the pull command will only work in a clone repository, since a clone has a link to the original repository. When you do a pull, you can specify the path to any repository so that you can fetch changes in a development branch.
Let’s now pull changes in the clone to the original repository.
> cd /projects/first-steps > git pull /projects/first-steps-clone master remote: Counting objects: 8, done. remote: Compressing objects: 100% (4/4), done. remote: Total 5 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (5/5), done. From /projects/first-steps-clone * branch master → FETCH_HEAD Updating a662055..9e7d7b9 Fast-forward bar.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Creating A Repository for Sharing
In addition to the pull command that takes commits from another repository, there is also a push command that transfers commits to another repository. However, the push command should be applied only to a repository where no developer is working. The best way is to create a repository with no workspace in it. Such a repository is called a bare repository. You use the --bare option of the clone command to create a bare repository. A bare repository can be used as a focal point to which developers transfer their commits (using the push command) so that others can pull changes. Figure 2.5 shows a bare repository.
Figure 2.5: A bare repository, a repository with no workspace
> git clone --bare /projects/first-steps /projects/first-steps-bare.git Cloning into bare repository first-steps-bare.git... done.
Uploading Changes with push
Figure 2.6: Sharing through a shared repository
To demonstrate the push command, change the first-steps/foo.txt file again and do the following to create a new commit.
> cd /projects/first-steps > git add foo.txt > git commit --message "More changes in the original."
Then transfer this commit using the push command to the shared repository (See Figure 2.6). This command expects the same parameters as the pull command, the path to the repository and the branch to use.
> git push /projects/first-steps-bare.git master Counting objects: 5, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 293 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /projects/first-steps-bare.git/ 9e7d7b9..7e7e589 master -> master
Pull: Picking up Changes
To bring the changes to the clone repository, you use the pull command with the path to the shared repository.
> cd /projects/first-steps-clone > git pull /projects/first-steps-bare.git master remote: Counting objects: 5, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From ../first-steps-bare * branch master -> FETCH_HEAD Updating 9e7d7b9..7e7e589 Fast-forward foo.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Attention! If another developer has done a push before us, the push command will reject the transfer. Then, the new updates by the other developer must first be picked up with a pull and merged locally.
Summary
- Workspace and repository: A workspace is a directory that contains a repository in a .git subdirectory. You use the init command to create a repository in the current directory.
- Commit: A commit defines one version for all the files in the repository and describes when, where and by whom the version was created. Use the add command to determine which files to be included in the next commit and then use the commit command to create a new commit.
- Getting information: The status command shows which files have been modified locally and what changes will be incorporated into the next commit. The log command shows the commit history. The diff command can be used to show the differences between two versions of a file.
- Clone: The clone command creates a copy of a repository called a clone. In general, every developer has a full clone of the project repository with the entire project history in his/her workspace. With this clone, he/she can work independently without connecting to a server.
- Push and pull: push and pull are commands for sharing commits between local and remote repositories.