Using+git+version+control+on+NAS

What is Git?
Git (the fast version control system) is a free and open source distributed version control system. It was initially created by Linus Torvalds (you know, that guy that wrote the first linux kernel ...) to maintain the linux kernel because BitKeeper, the system that was used until then, was withdrawn from free use (kinda like the story of Unix and GNU). It's design is based on CVS and BitKeeper Since than it has grown to a revision control system that is capable to use in big projects (the linux kernel, Qt, Gnome, ... ) and small(er) projects (probably like your own). Compared to subversion it is better in handling the creation and merging of branches.

Basic git usage
The first step is the creation of a local (copy of) a repository. This can be done in two ways
 * 1) creating a repository from a local directory
 * 2) checkout an existing repository

Creating a repository from a local (source) directory
code git init code code git add. code This will add all files (and subdirectories) of the local directory to the git repository.
 * go into the directory
 * execute the command
 * in this directory a new directory is created, named ".git" which holds all the necessary information
 * to apply version control on the files, you have to add them to the project

Checkout an existing repository
code git clone URL-TO-REPOSITORY code code git clone git://git.kernel.org/pub/scm/git/git.git code
 * execute the command git
 * for example, to download the repository of the git project:

Branches
A branch version line of your code. The existing branches can be seen with the command code git branch code The default branch, and also the branch that is created when initializing or cloning a repository, is the "master" branch. The active branch is indicated with a star in front of the name when executing the git branch command. To change the active branch, you have to checkout the different branch. code git checkout OTHER-BRANCH code The content of the directory will change to the content of the most recent commit in the checked-out branch. The most recent commit in the active branch is pointed to with the reference variable HEAD. So if you change branch, this variable will point to the most recent commit of the checked-out branch. When you change files and commit them, this commit will be added to the active branch, and this also implies the change of the HEAD variable to the new commit. The HEAD variable can be used as a reference to checkout earlier versions of the branch or to undo recent commits.

If you clone a repository, you get the most recent commit of the active branch of the project, but also the information of the branches that exist in that project. It is possible to see the other branches of the project by executing the command code git branch -r code To checkout a other version, you have to execute the command code git checkout PATH-TO-BRANCH -b NEWBRANCHNAME code for example code git checkout origin/todo -b todoBranch code This will create a new branch with the content of the "origin/todo" branch. It is possible to checkout without the creation of a new branch, put this implies that the checked-out content is out-of-branch. You can still read files and even commit, but the commit can only be referred to by its hash-code (which is given when doing the commit).

To create a new branch based on the most recent commit of the active branch, you execute the command code git branch NEW-BRANCH-NAME code To make this new branch the active branch, you have to execute a checkout.

Of course it is possible to merge branches. To merge the active branch with another branch you execute code git merge OTHER-BRANCH-NAME code Git will try automatically to merge the files of the two branches. If their are conflicts (for example multiple versions of a function call), they will be indicated in the relevant source files. You have to solve these conflicts first before these can be added to the git repository. The merged branch will form the new content of the active branch.

Tags
Contrast is a system of named references to specific versions. While your project progresses, their will be certain versions that can be marked (like in the linux kernel there are stable releases, named by their number, and experimental versions). These versions can be tagged with a name. In contrast with the HEAD reference, a tag will always refer to the same commit. You can see the tags with the command code git tag -l code These can be checked out in the same way as remote branches code git checkout TAG-NAME -b NEW-BRANCH-NEW code for example code git checkout v1.7.9.1 -b branchv1.7.9.1 code

Ask for information
Sometimes it can be necessary to read the comments about commits. This can be done by using the command code git log code log has many options to define from which commits the information must be shown, and how extensive this information has to be (only the first line of the comment, the full comment, ...). It can be useful to read the man page of git-log to look into the different options.

Adding files to the repository
Of course it would be very useful of we could add files to our repository. Git track of changed files by using an index. This index keeps the files that have to be inserted into the repository when executing the commit command. When you just checked out a new version or committed your most recent changes into the repository, the index should be empty. This can be checked with the command code git diff --cached code which shows the difference between the HEAD and the index (so, which changes will be added in the next commit). code git diff code shows the changes between the working tree (the files) and the index. To update the index, you have to add the files with the command code git add source.cpp code when the files are added to the index you execute the command code git commit code to add them into the repository. Git will open an editor to add a comment about this commit. The first line will be used in short log information messages, so it should containt a short description of the commit, the rest will be shown when the complete commit-information is asked so it can describe in detail what this commit contains, why these changes, possible shortcomings, ...

Git contains a shortcut for adding and committing files code git commit -a code This command will both add the files to the index and commit them.

Further information
A more complete manual of git (where this information is based on) can be found at @http://schacon.github.com/git/user-manual.html

Access git repositories on the NAS
The EAVISE NAS system is been provided with a git system for version control on the source of different projects. Everybody with an account is able to access the git repositories on the NAS by using ssh. code git clone ssh://username@nassen.denayer.wenk.be/GIT/voorbeeld.git code This will create a local directory "voorbeeld"(the name of the repository) with the content of the repository. Git remembers the origin of the clone, so when you will execute a pull, push, ... operation it will automatically ask for your ssh password.

You can develop in your local copy of the repository like seen before (changing files, commit them to your local version). Since it would be useful if others could see it would be helpful to add the commitments to the public available repository on the NAS. code git push code If you create a new branch in your local copy and you want it added to the remote version of the branch, you have to execute code git push origin NEW-BRANCH-NAME code

Create a new repository on the NAS
When you have a source directory which you want to put on the NAS, you first have to make a bare repository of it (only the .git directory, checked out files around it) code git clone --bare SOURCE-DIRECTORY PROJECT.git touch PROJECT.git/git-deamon-export-ok code This last command tells git that it is a public repository. This makes the push operation of your local versions to the repository on the NAS a lot easier.

The next step is putting the created repository onto the NAS by using scp code scp -r PROJECT.git nassen.denayer.wenk.be:/GIT/ code From now on it is possible to checkout the version on the NAS. It is recommended to check out this remote version to a new local directory as your working copy, since the configuration for pushing changes to the NAS-version will be correct this way.

Pulling the most recent version
If you work with multiple persons (or from different computers, or multiple checked-out versions, ...) it can be useful to pull the most recent version of the repository to you local version code git pull code