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
creating a repository from a local directory
checkout an existing repository
Creating a repository from a local (source) directory
go into the directory
execute the command
git init
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
git add .
This will add all files (and subdirectories) of the local directory to the git repository.
Checkout an existing repository
execute the command git
git clone URL-TO-REPOSITORY
for example, to download the repository of the git project:
A branch version line of your code. The existing branches can be seen with the command
git branch
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.
git checkout OTHER-BRANCH
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
git branch -r
To checkout a other version, you have to execute the command
git checkout PATH-TO-BRANCH -b NEWBRANCHNAME
for example
git checkout origin/todo -b todoBranch
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
git branch NEW-BRANCH-NAME
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
git merge OTHER-BRANCH-NAME
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
git tag -l
These can be checked out in the same way as remote branches
git checkout TAG-NAME -b NEW-BRANCH-NEW
for example
git checkout v1.7.9.1 -b branchv1.7.9.1
Ask for information
Sometimes it can be necessary to read the comments about commits. This can be done by using the command
git log
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
git diff --cached
which shows the difference between the HEAD and the index (so, which changes will be added in the next commit).
git diff
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
git add source.cpp
when the files are added to the index you execute the command
git commit
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
git commit -a
This command will both add the files to the index and commit them.
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.
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.
git push
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
git push origin NEW-BRANCH-NAME
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)
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
scp -r PROJECT.git nassen.denayer.wenk.be:/GIT/
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
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 waysCreating a repository from a local (source) directory
- 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
This will add all files (and subdirectories) of the local directory to the git repository.Checkout an existing repository
Branches
A branch version line of your code. The existing branches can be seen with the commandThe 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.
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
To checkout a other version, you have to execute the command
for example
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
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
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 commandThese can be checked out in the same way as remote branches
for example
Ask for information
Sometimes it can be necessary to read the comments about commits. This can be done by using the commandlog 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
which shows the difference between the HEAD and the index (so, which changes will be added in the next commit).
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
when the files are added to the index you execute the command
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
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.htmlGit on NAS
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.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.
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
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)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
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