Välkommen till Callista Enterprise blogg - här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad genom att följa oss på Twitter.
Callista Enterprise medarbetare Jan Västernäs

Getting started with git

// Jan Västernäs

Having used Subversion for a long time I wanted to learn how to use a distributed versioning system. The selling points for these products are very interesting.

For instance the possibility to separate commit from delivery seems like a nice option. If you work on something that takes a couple of days to do, you want to commit often even when only parts of the work is ready without disturbing your colleagues. You want to commit even if all tests are not green. You want to be able to experiment and throw some stuff away by going back to previous committed versions. With a DVCS (Distributed Versioning Control System) you do all of this in your local repository and only when you are finished you deliver to the project repository where other people then can use it.

Which product should you use ? Git and Mercurial seems to be the popular choices. Based on the post Git is McGywer and Mercurial is James Bond I choose Git, although I’m not a command-line wizard.

Installation on OS-X is very easy as expected. I used http://git-scm.com/download. In windows it is a bit more complicated because you have to choose between 2 different setups. I choose the option without Cygwin and running bash in command windows. I wonder who has the balls to choose the third option in this question?

Anyway creating a repository and checking files in is very easy

$ mkdir repo
$ cd repo
$ git init
Initialized empty Git repository in /Users/jan/repo/.git/

$ touch file1
$ git add .
$ git commit -m "Added empty file1"
[master (root-commit) a08c807] Added empty file1
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file1

The init command will create the repository. The only bit of magic is the git add command. It will add one or many files to something called the index. Only changes added to the index will we affected by the next git commit.

Now you can start playing around with creating branches, make changes and merging branches. Working with branches is much less expensive than you thing and a recommended way of using git.

But having only a single repository probably is not want you want to do. Collaboration between different team members is of course the next thing to try out. In order to understand how that work I did like this.

$ cd ..
$ git clone repo clone1
Cloning into clone1...

$ git clone repo clone2
Cloning into clone2...

Now you have three complete repositories. You can imagine that clone1 and clone2 are local repositories at different users and that repo the a project common repository. I used three different command windows, one for each repo. Then it was easy to change something in clone1, push it to repo an pull the changes to clone2. Also simulating conflicts and how to resolve them is very easy since you have full control of all three repos.

$ cd clone1
$ touch file2
$ git add .
$ git commit -m "added file2"
[master bacb66b] added file2
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file2

$ git push
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing object: 100% (2/2), done.
Writing objects: 100% (2/2), done.
Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
To /Users/jan/repo
   a08c807..bacb66b  master -> master

$  cd ../clone2
$ ls -l
total 0
-rw-r--r--  1 jan  staff  0 Oct 26 08:07 file1

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From /Users/jan/repo
   a08c807..bacb66b  master     -> origin/master
Updating a08c807..bacb66b
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file2

$ ls -l
-rw-r--r--  1 jan  staff  0 Oct 26 08:07 file1
-rw-r--r--  1 jan  staff  0 Oct 26 08:17 file2

In conclusion getting started with Git is easy. Mastering all (or much) of the Git functionality and different distributed repository topologies will probably take much longer.

Martin Fowler makes an interesting comparison between different products

From this you can see that Git and Mercurial are useful but more complex to learn.

When it comes to topologies I think that Scott Chacon has some nice pictures, how about this one :

Some useful resources

And .. this video is a must

Tack för att du läser Callista Enterprise blogg.
Hjälp oss att nå ut med information genom att dela nyheter och artiklar i ditt nätverk.