You will have "trunk", now called "master", you will have "branches" now called "heads" and you will have "tags", still called "tags", but they won't be folders, they will be "refs", labels to revisions that live in separate namespace inside the repository.
Subversion and Git have different ways to do branching. The basic subversion model is to have a directory tree with single global timeline and if you want to branch, you copy a subtree in another directory.
On the other hand Git has a directory tree with revisions that each defines it's parents, but each revision can have multiple parents (a merge) and multiple children (branches). So instead of having directories for branches, you get independently created revisions. The "refs" are just names associated with latest revision for given "branch".
This difference is fundamental to distributed version control. Git (and other distributed systems) does not have any central authority to keep the history linear, so revisions can be created independently on multiple repositories without knowing about each other and the system has to accommodate them. It turns out the generalization makes branching and merging a lot easier in general.
Note, that in Git, revisions are not on any branch. They just are and branches contain them. But once branch is merged, or proves to be dead alley, you can just delete the "ref" pointing to it and forget about it altogether (if you discard old trials, they will be garbage-collected eventually with
git gc). This helps you avoid getting swamped in old experiments nobody remembers what they were about anymore.