As this is tagged with git I hope that my lack of SVN knowledge is neglectable.
Currently I am cloning a repo and clone a specific branch using gitk.
You are cloning the whole remote repository not only a specific branch.
The repository is best imagined as a database, so you are making a clone of the current state of the remote database. But after that, you are working on your own copy of that database; if you commit, you alter your local database.
fetch command is used to keep the local database in sync with the remote one.
Usually from that local database, you checkout a branch to work on. This is nothing else like an internal marker for git, where your current work began.
Say, you are working on a simple repository, where there is no branch besides
master, you could take a look into the
.git folder to unveil the "magic":
Assume your last commit (on
182e8220b404437b9e43eb78149d31af79040c66, you will find exactly that under
From that you branch off a new branch
git checkout -b mybranch, you will find the exact same pointer in the file
Branches are nothing more than "pointers". The "working" marker is called a
If you want to know where your
HEAD is at:
cat .git/HEAD which says e.g.
ref: refs/heads/mybranch, which in turn points (
cat .git/refs/heads/mybranch) to a commit hash
The actual commits are stored under the
objects folder (the how is a topic of its own).
The project folder contains only the content for that branch and I cannot see all branches as in SVN, which is a little confusing for me.
Don't confuse the
working directory with the "git-database" as a whole.
As I said above, your working directory is only a snapshot of (maybe) a subset.
Say you have different branches, your working directory is dedicated to working on that branch only (although you could put the work from there elsewhere).
Usually, if you want to see, what branches are defined for the project, you have the possibility of
git branch for local branches
git branch --remote for remote branches
git branch -a for both
git branch -v)
Since git is a distributed version control system it is not only possible, but encouraged, to make different branches locally / remote.
My typical workflow is:
- branch a feature branch off
- branch a WIP (work in progress) branch from that
- work like however you want - even if you commit after a single line; it doesn't matter
When the feature is complete:
- squash/rework the
WIP branch (with interactive rebasing) = make a single commit from that
- merge the
WIP branch into the feature branch and offer that (if you work with github that offer would be called a "pull request") to integrate into the stable (master) branch.
Also I would like to know how to handle a process where I need to wprl on two branches at the same time in case, for example, I need to make an hotfix on master but keep the content of another branch too.
It depends on how your project is structured:
Say you have a stable master. And features are only developed off from that stable branch - so it is usually behind a feature branch. Then you would have a last commit on master that would be the root of the feature branch.
Then you would make a commit on the master branch and could decide, whether to merge both branches together or to rebase (which is a kind of merge for users with advanced needs so to say).
Or you are always able to make changes on branches ( e.g.
master) and cherrypick them on to other branches.
What is a recommend name conventions to make the folders which include the branch cloned from the repo in GIT, example myproject-branchname
It is up to you.
Typically, you end up with the repositories name.
But there are occasions, when this is not wanted:
e.g. you clone oh-my-zsh with
git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
.oh-my-zsh is explicitely named as the target.
git cloneis more like
svnadmin loadthan it is like
svn checkout. With
git, you don't request bits and pieces from the repository; you copy the entire repository and work with it locally, pushing changes back to the "source" repository when and if you feel like it. Git and Subversion use two entirely different models for source control.
gittagged questions skip this one, thinking it is done already. Just saying. Give it 24 hours before accepting, to increase the chance to generate more diverse answers. You might want to re-evaluate the answery you got and check if you want to switch...