Hi Stefan,
Generally with git, your entire working copy will have the same
revision (set to current branch, aka HEAD). The idea behind this
is that your working copy of a repository should always be in
consistent state.
You can check out specific files or directories from another
revision (mimicking "svn update -r1234 filename"):
$ git checkout branch-or-sha-hash -- filename
However, SVN tracks the 'revision' thing on per-file basis, while
in git this is a property of the working copy. So if you do like
above then git will be telling you that the 'filename' has been
changed (as it is certainly different from its pristine version
in HEAD):
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: filename
So it's generally not recommended to do such a thing.
Another thing that you _can do_ in git to mimick SVN is the
'standard layout'. There is a feature called "git worktree" which
allows you to have SVN-like directory structure with multiple
directories linked to different working copies:
$ mkdir my-project
$ cd my-project
$ git clone my-project-repository master
$ mkdir branches
$ cd master
$ git worktree add -b branch-1 ../branches/branch-1
$ git worktree add -b branch-2 ../branches/branch-2
After that you will have directory structure like this:
$ tree my-project
my-project
├── branches
│ ├── branch-1
│ │ ├── 1
│ │ ├── 2
│ │ └── 3
│ └── branch-2
│ ├── 1
│ ├── 2
│ └── banana
└── master
├── 1
└── 2
You can work with these working copies separately, like you
would be working with SVN. Commits in 'master' will go to the
'master' branch, commits made in 'branches/branch-1' will go
to the 'branch-1' branch.
