I want to make a git bare repository with multiple branches (master, develop, release, etc..). So question is if it is possible to checkout the bare repository or how to switch among the branches (does it make a sense to switch)?
When I want to push to the bare repository can I make a merging on bare repository or merging must be done locally and push the adequate branch? So looking for a right approach :-)
Thanks Peter
I want to make a git bare repository with multiple branches (master, develop, release, etc..).
Judging from the question, it seems that you are unsure of the reasons you would make a bare git repository, and how you would use said repository. The question is, why do you wish to make a bare repository?
From Pro Git, a bare repository is "a repository that doesn’t contain a working directory." It's a repository that you don't work out of, and is just used to git push and git pull from. The reason for this is summed up here:
"A bare repository is one without a checked out working copy of the code. It only contains the git database. As a general rule you should never push into a repository that contains changes in the working copy. To ensure this doesn't happen, we're making the server repository a bare repository - it has no working copy."
So, a bare git repository can definitely contain multiple branches. You can definitely fetch a copy of the bare remote repository into your local repository, and push from your local repository to your remote (bare) repository. However, you don't want to work out of your bare repository. (Furthermore, it is impossible to run git add whilst in a bare repository; see this SO question for clarification).
So question is if it is possible to checkout the bare repository or how to switch among the branches (does it make a sense to switch)?
This question, I think, is not entirely clear, because you never really switch branches on the bare repository - you never work on the bare repository. All you do is push or pull from it.
When I want to push to the bare repository can I make a merging on bare repository or merging must be done locally and push the adequate branch? So looking for a right approach :-)
To git-push to a bare repository, you must first ensure that there is no merge conflict - if there is, the push will fail (Reference: book.git-scm.com, "Pushing changes to a public repository"). Merging must therefore be done locally, and then changes fast-forwarded on the bare repository with git-push.
So looking for a right approach.
There isn't anything special about a bare repository, aside from the fact that you should not and can not work out of it. As others have referenced, the gitflow model gives you an idea of a workflow involving several repositories - there are lots of questions on SO asking for git workflow examples and methodologies. Almost every reference (1, Pro Git), (2, book.git-scm.com) uses a bare repository in conjunction with a public or published repository - the linked articles discuss creation and use of bare repositories in detail.
The question is a little unclear with what you're trying to do. Git doesn't enforce a specific workflow model. The idea is to leave it up to you -- The development team. Based on the branch names you posted, it seems to me that you're leaning toward the gitflow model, which is a very successful workflow for many companies and development teams.
When you initially create a repository (if it does not exist on a remote server somewhere), you'd use git init which creates a new repository with a default master branch. You can then add your files using git add and commit: git commit. When you're ready to push to your remote git server (such as github), you'd add the remote git URL using: git remote add origin <url> and push your repository to the server using git push origin master
If you already have a remote server you wish to clone the repository from, you'd use git clone <repo url> which pulls down the repository and points you to the default branch (typically master).
Switching branches is useful for when you want to do development on a feature branch and then later merge it in (for example), or when your code is ready for a release, branch into a release branch and eventually merge it into a live/production branch. See the gitflow model for details on doing it that way.
For getting started with git, I recommend reading through the documentation on github, starting with 'beginner'. You can read more about what git is and some basic commands on the A List Apart Get Started with git article as well.
