Version control


Git is used as version control system of the Linux kernel source. One really nice feature is that it needs no tricky setup. The software can be developed in a directory not be worried about version control. Once the need having a version control system pops up, the program git needs to be installed the usual way as any other program on your Linux distribution. Using git the hidden directory .git will be added there where the source code is developed. A bare repository is kept inside this hidden directory .git that holds everything a version control system needs. The code being developed in the above directory becomes the working tree. In case of putting it on a server to have a master for different persons, just the content of the bare repository is required and no working tree makes sense to have on the server.

For git see: To get help type man git-<git command> or git help<git command>

Before you start the first time with a fresh git installation let git know who you are, so it will know in the future who has done what when you work in a team:

git config --global "<your name>"

git config --global "<your@email>"

To put a project under git clean up the directory first, it is recommended that object files, backup files and executables are not in the same directory (however a file .gitignore can be added that controls what will be checked). To put all files in the directory under git do:

cd <working directory>

git init

git add .

git status

git commit -m 'Initial commit'

To add individual files (git add . adds all files) under git (or use wildcards as git add *.c), do:

git add<new file1><new file2>


Git uses two steps to put the files in its archive. First you add them, then you commit them.

After that you can work normally. When you think it is time to have a good status of you work type:

git status

to see what you have done. You will see what files you modified and what files you created new, plus what new steps you can do with git.

After that do a:

git commit

If you have a clean directory (no backup files, no objects and runnable executables), you could do this faster by:

git commit -a

To see what you have done (key Q brings you back):

git log or the more compact version git log --oneline important is the commit id or just the first 10 characters of the commit id as git log --oneline shows

Ignoring files and directories

Inside the directory that git observes, there might be files and directories that should not be version controlled. Such directories and files might contain files automatically produced be integrated project environments.

To ignore files and directories, put the file .gitignore inside the directory. It is a text file that could contain something as:

# ignore backup files
# ignore compilation results

Going back

If not yet committed, getting rid of recently done modifications is easy. git status shows what has been modified since the last commit. git checkout -- <filename> will then get last version. -- seems to be there to mark the name as filename. If -- is missing then a commit name with the same name as the file might be taken. git checkout -- . will do it with all files not committed.


If it comes to release, you should give your release a tag. Commits are identified by a commit number as af8dad733ecf500a859a09357576cbb5605cf543 that can be obtained by git show, git log or git log --oneline. Instead of dealing with those numbers or descriptions, commits can be tagged either by git tag v1.0 or git tag v1.0 af8dad733ecf500.


The commit number does not have to be inserted completely, It just needs enough characters to be unique.

To see what tags there are type git tag

To create a zipped tarball of the latest version (HEAD)in the working directory (make sure you have committed everything):

git archive -o<name of the archive>.tar HEAD && gzip <name of the archive>.tar


If a well working version gets larger risky modifications or if a second programmer starts doing something, it is worth to make a branch, this means a new version that exists in parallel to the stable version the master. If everything goes well the branch can be merged with the stable version at some future moment, if not the branch can be deleted. To see what branch you have the type:

git branch


More important * shows you what branch you work on

To create new branches type:

git branch<name of new branch> <tag from where it branches>

To checkout the branch (creating does not checkout):

git checkout<name of new branch>

To create and checkout

git checkout -b <name of new branch>

To merge the branch to the master:

git merge<name of new branch>

To delete a branch

git branch -d<name of new branch>


On local filesystem the directory containing git (the git repository) could be simply copied but the clean way is git clone file://<path to local source directory><path to destination directory>


git clone <path to local source directory><path to destination directory> will try to create hard links between source and destination. so use file:// do have a real copy.

Remote repository are bare repository that have no working directories (working tree) where the files are checked out. The purpose of a remote repository is that the files checked out are on a remote machine and not on the server. A remote bare repository is a .git directory with a visible (not hidden) directory with a name as <name>.git.

Such a remote bare repository can be created from a regular repository.

git supports different ways of communication. The following uses http and does not require to have git installed on the server. On the server machine run

cd /var/www/htdocs or where your server data is

git clone --bare <path to the source repository><name of remote repository>.git

Some magic work needs to be done

cd <name of remote repository>.git

mv hooks/post-update.sample hooks/post-update

chmod a+x hooks/post-update

git update-server-info

Now when the magic is done a user can clone it with git clone http://<server name>/<name of remote repository>.git


Git has also its Gui:

git gui



Since this GUI is quite complex to support everything it is recommended to not loose focus and start first with the simple console commands.

CVS ( Concurrent Version System)

It is a tool that allows multiple software developers work simultaneously on the same project and handles different versions and releases. An other version control systems is: subversion, snv

Two branches (working activities) are commonly used:

  1. stable branch (Base branch) => just bug fix work being done

  2. unstable branch (Head branch)=> work to add new features

The unstable branch gets frozen from time to time to make releases


  1. Major releases have new features, therefore when an unstable branch get frozen the major release number will be increased.

  2. Minor releases are bugfixes of the stable branch and the minor release number gets increased.


myprogram-3.2 => 3rd major release with 2nd minor release.

kde-3.5.2 => 3.5th major release, 2nd minor release

The CVS repository (main repository) is usually on a server but can also be local (local repository) when you make local development. The actual work is done in a working folder (synonyms: working copy, sandbox). CVS is a client sever architecture, where the CVS server is on the net somewhere as and a CVS client is on your computer. If you have a local CVS repository then client and sever is on your machine.

To get the files in the working folder you need to checkout the module (module is the word for a CVS project, e.g. the program being developed).

Having once the files on the computer they can be updated to receive the changes from the colleagues working on the same files.

Committing is the command to store your work done in the repository.

CVS Internals

Inside the CVS repository there is a subfolder CVSROOT and subfolders for each project (or module) that has been created.

The files in the repositories are not stored in the same form as in the working directory. To the filenames ,v is added and the text-files get a CVS header whereas the original text is moved in between two @ characters. Therefore no additional files are required in the module directory of the repository. This is also one reason why to take care how to use binary files with CVS.

The local working directory gets all the source files and has a CVS subdirectory containing internal CVS data.

The CVSROOT subfolder inside the repository holds CVS internal data.


CVS is a command line tool but Cervisia is a GUI (graphical user interface) frontend for CVS. Useful Cervisia configuration:

In the Settings menu, check the Create Folders on Update box, the Prune Empty Folders on Update box and the Update Recursively box, directly on the menu.

Now, still on the Settings menu, click the Configure Cervisia... menu item.

Click the advanced icon in the icon list and set the Default Compression Level drop down to three. Press OK.

Cervisia has two windows one containing the files of the repository and the other one showing the CVS text commands issued and the responses.

Exporting files is used for making a release and does not copy the CVS subfolder. Tags are used to mark releases snapshots that later can be recreated. An alternative is using the date for that. It is obviously that you can not change and commit to the same date and tag (unless the tag is a branch tag). Tags are usually given a name consisting of the project name and the version number.

Tags are usually linear except branch tags that can create a branch and therefor leave the trunk. The trunk points to the head branch that grows up.

Leaving branch empty means head branch.

Revision A and B in the browse log are just used to mark a range of versions from version A to B to e.g. to see differences or create patches between versions.

How to create a repository

It is worth to create an empty subfolder in the CVSROOT, then checkout it to the working directory. Copy all files to the working directory, add them to the repository.

Watch out for binary files! For binary files don't use the add icon or the file->add to repository since this adds the mentioned header to the files and might corrupt them. Use instead the file->add binary command.

Then you have to commit all files so they appear in the repository. An alternative would be the Cervisia import module command.

Creating a Local Repository

mkdir /home/user/cvsroot

cvs -d /home/user/cvsroot init

mkdir /home/user/cvsroot/myproject

Finding The Repository Location And The Retrieval Method



Example for local


Setting The Repository Location And The Retrieval Method

Using Cervisia to set the location: Cervisia has the ability to store different repository locations.

To add a repository location, click the Repository menu then the Repositories... menu item.

The Configure Access to Repositories dialog box will pop up.

Press the Add... button. The Add Repository dialog should appear.

Type the repository location in the Repository text box. Press OK.

If your repository's retrieval method is pserver, you still have to log in. The Status column is probably showing Not logged in.

Press the Login button. If you are using an Anonymous CVS mirror just hit enter. Else, type your password. If everything went well, now the Status column should show: Logged in.

If you want, add another location. Cervisia will store as many locations as you like!

Other version control systems

subversion is supposed to be the successor of cvs see:

Linurs Servernest startpage