| Free tutorials for Java, Eclipse and Web programming |
Version 3.4
Copyright © 2009 - 2011 Lars Vogel
04.01.2011
| Revision History | ||
|---|---|---|
| Revision 0.1 | 13.09.2009 | Lars Vogel |
| Created | ||
| Revision 0.2 - 3.4 | 21.11.2009 - 07.06.2011 | Lars Vogel |
| bug fixes and improvements | ||
Table of Contents
Git is a distributed version control system (dvcs) written in C. A version control system allows that you can create a history for a collection of files with the possibility to revert them to another state. These collection of files is usually called "source code". In a distributed version control system everyone has a complete copy of the source code (including the complete history of the source code) and can perform version control operations against this local copy. The usage of a dvcs does not require a central code repository.
If you do changes to the source code you mark them as relevant for the version control (add them to the index / staging)) and then you add them to the repository (commit). Git maintains all version you can revert to any point in your source code history via Git. Git performs commits to your local repository and you can synchronize your repository with other (remote) repositories. Git allows to clone repositories, e.g. create a exact copy of a repository including the complete history of the source code. Owners of repositories can sychronize changes via push (transfer changes to a remote repository) or via pull (getting changes from a remote repository).
Git supports branching, e.g. you can have different versions of your source code. If you want to develop a new feature you may open a branch in your source code and make the changes in this branch without affecting the main line of your code. Git keeps track of all versions.
Git can be used from the command line; this approach will be described in this tutorial. You also find graphical tools for example EGit for the Eclipse IDE .
Table 1. Git Terminology
| Term | Definition |
|---|---|
| Repository | A repository contains the history, the different versions over time and all different branches and tags. In Git each copy of the repository is again a complete repository. The repository allows to retrieve revisions into your working copy. |
| Branches and Tags | A Git repository contains always all branches and tags. One of the branches is the default (normally named master). The user checkout a version branch to work in this branch, this is called the "working copy". |
| Commit | You commit your changes into a repository. This is create a new revision which can be later retrieved, for example if you want to see the source code of an older version. Each commit contains the author and commiter fields which identifies how create the change and who commited it. |
| URL | An URL in Git determines the location of the repository. |
| Revision | Represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160-bit long and are represented in hexadecimal. The latest version can be address via "HEAD", the version before that via "HEAD~1" and so on. |
Git requires you to mark changes explicit to be relevant for committing them to the repository. For example if you what to have a file or changes in a file being relevant for the next change you have to add them to the so called "staging index" via git "add file". For files which were already committed once you can use the the "-a" flag during a commit. The staging index will be a complete snapshot of the changes.