On Mon, Aug 20, 2012 at 03:27:39PM -0300, Gabriel Lau wrote:

> In my case I use a bare repository. It was the easiest way I've found to
> manage the projects sent to the server.
> I start a new repository as bare and set it to put the files of the
> project in a specific directory in the server.
I don't get this sentence: bare repos by definition have no workng tree
attached to them.  Do you mean you set up post-commit hooks in these
repos which do check out the files to a (detached) working tree (by
means of using GIT_DIR, GIT_WORK_TREE env. variables or so)?

> But some of those projects I want to set a second branch to test
> some things when needed and switch back to the master when I finish
> testing.
If the answer to my previous question is "yes", then you have almost no
problem at all: a bare repo differs from a non-bare repo only in that it
does not have a workng tree; it still can maintain any number of
branches (and tags) in it, commands like `git branch` do work in it, and
any branch/tag/commit can be checked out to a (detached) working
tree, and several working trees can be maintained in parallel.

So basically you should work along these steps:

1) Push your experimental branch to a remote repo:
   $ git push server mystuff:experiment

2) Log in to the server, create a directory for your experimental files,
   then do:
   $ export GIT_WORK_TREE=/path/to/that/directory
   $ export GIT_DIR=/path/to/your/bare/repo
   $ cd $GIT_WORK_TREE
   $ git checkout experiment

3) After you have verified everything works okay, delete that
   experimental branch--either from the server side, by running
   `git branch -D experiment` from within the bare repo directory,
   or from the client side by pushing nothing to that branch:
   `git push server :experiment`.

You might as well go further and wish to perform certain fixups
to your experimental while testing the code on the server; in this case
you could use the GIT_INDEX_FILE variable to point Git to a file to use
as the staging area for your experimental working tree (you still need
the above mentioned env. variables set as well).  This would allow you
to do any number of commits to fix your experimental code and then
fetch them from the client.  Read more on this topic in [1].

If checking out code to a detached working tree is not your way of work,
and my guess failed, please be very specific about your setup as it
seems not too much people here understand it (me included).  As usually,
not trying to be too formal when explaining helps considerably: a simple
example (or a few of them) formulated in simple words will do just OK.

1. http://git-scm.com/2010/04/11/environment.html

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to