git repositories

Much can and has been said about the benefits of maintaining a code repository with version control. In short, version control systems will give you the opportunity to revert back to a previous state of your code ( or any other collection of files ) or work on different 'branches' of your code simultaneously, without having to manually copy your complete working directory to various backup directories. In theory, this allows for a lot of flexibility and safeguards against doing irreparable damage to your code.
There are several version control systems, most notably SVN, CVS and GIT. Git is the cool new kid on the block and a lot of open source projects are being developed using so called git repositories. Often these projects are stored on online servers of which github ( www.github.com ) is probably the most widely used at this moment. Git is installed on our TBB machines and you do not need an online repository account to start using it. Many tutorials for git exist, for example
here or here [broken link?] or here (html/pdf/paper) and you can even test drive git in an online simulation tutorial

making your code accessible from your website

Try the following ( kindly provided by Jan Kees ) and read README for full instructions:

go to your favorite test directory on your computer and then type:

git clone http://bioinformatics.bio.uu.nl/jankees/git/git_via_http.git

[TODO: make a simple example for noobs]

Summary of basic Git commands

This is basically a very sparse summary of the tutorial/book "pro git". It covers the basic commands and a few important technical details.

set some global info and preferences

$ git config --global user.name "John Doe"
$ git config --global user.email john@doe.com
$ git config --global core.editor kate

make sure to install meld (or another tool) for a GUI diff output

$ git config --global diff.tool meld

the same holds for the merge tool. meld does both..

$ git config --global merge.tool meld

set up aliases for git commands
two common examples:

$ git config --global alias.unstage 'reset HEAD --'
$ git config --global alias.last 'log -1 HEAD'

make a new git repository in an existing folder

$ git init

add files to be tracked

$ git add makefile
$ git add src/*.cpp

undo staging

$ git reset HEAD <recently added/staged file>

commit for the first time. not using the -m option will open an editor

$ git commit -m "initial project version"

by default, commit only commits the (manually) staged (added) files.
The re-adding can be done automatically with the -a option

$ git commit -a -m "all new changes staged and committed!"

do a quick fix after a commit (add a file that you had forgotten, change message)

$ git commit --amend -m "all new changes staged and commited! awesome!"

make a local copy of someone else's project

$ git clone https://github.com/johndoe/johnsproject <optional local target folder>

If you do not want to copy the entire history of a project, but just the latest commits, use the option --dept
$ git clone https://github.com/johndoe/johnsproject --dept 1

display the status (--short gives a more parseble output)

$ git status [--short]

give an overview of all commits

$ git log

stage a file for the next commit: i.e. add the file to the next commit

$ git add <recently modified file>

make a .gitignore files to ignore untracked files

## my .gitignore file
## ignore everything with an .o or a .d extention
*.[od]
## ignore the data folder
data/
## temporary files
*~
## ignore everything in the man folder
man/*
## but not the file manual.tex
!man/manual.tex

list changes in files that are not yet staged

$ git diff

list changes in files that are about to be commited

$ git diff --staged

use a GUI to view changes (e.g. kompare)
WARNING: don't save the file unless you want to REVERT changes

$ git difftool

remove a file from the git staging area (stop tracking) AND remove from disk

$ git rm obsolete.txt

remove a file from the git staging area (stop tracking) but keep the file in the working area

$ git rm --cached akward_todo_list.txt

moving and renaming: call shells mv command, and inform git about it

$ git mv filenameA filenameB

undo changes to modified file (i.e. replace file in the working area with the (old) file in the stageing area)
WARNING: THIS IS DANGEROUS, could destroy recent work

$ git checkout -- <file with bad changes>

List remote repositories. -v gives the url

$ git remote [-v]

add a remote repository. <alias> is a short-hand for the url (e.g. origin)

$ git remote add <alias> <url>

download new data from the remote repository my_repos.
NB: this does not do any merging (working area remains unchanged). See also "git clone" and "git pull"

$ git fetch my_repos

share new data on a remote server <alias> on the branch <branch>

$ git push <alias> <branch>

show info about a remote repository <alias>

$ git remote show <alias>

remember passwords for remote repositories

$ git config credential.helper store

listing tags

$ git tag

creating lightweight tags

$ git tag <tagname>

creating annotated tags

$ git tag -a <tagname> -m "add a message to the tag"

share a tag <tagname> on a remote server <alias>

$ git push <alias> <tagname>

or share all tags at once:

$ git push <alias> --tags

create a new branch (a pointer to a commit object)
NB: master is just a branch created by init
also note that HEAD still points to the branch you were working on (e.g. master)

$ git branch <name new branch>

switching between branches can be done with the checkout command:
NB: the checkout command changes the files in the working directory!

$ git checkout <name alternative branch>

creating a new branch, and moving to it at the same time (checkout is trivial)

$ git checkout -b <name new branch>

get a quick overview of the branches

$ git log --oneline --decorate --graph --all

merging a branch (possible_fix) with another (master)

$ git checkout master # first return to the master branch (after commiting possible_fix)
$ git merge possible_fix # then let master point at the same commit as possible_fix

if a merge creates a confict, you can use "git status" to see whatever is failing
otherwise, deleting an obsolete branch can be done with:

$ git branch -d <obsolete branch>

get an overview of all branches, and some info:

$ git branch -v

only list merged branches (that could be deleted..)

$ git branch --merged

of all un-merged branches (that might require some more work, or contain usefull new features

$ git branch --no-merged

[to be continued...]

Editors with Git support

Some IDEs (integrated development environments) that support Git (and other VCSs) are Eclipse and Atom.
Eclipse can be rather "heavy" and runs on Java. Atom is created by the GitHub people, and appears a bit lighter and more basic (although you can apparently "hack" it in many ways).