On Mar 3, 7:19 pm, Konstantin Khomoutov <khomou...@gmail.com> wrote:
> On Mar 3, 5:01 pm, vfclists <vfcli...@googlemail.com> wrote:
> > I am new to git and there is an issue I want to clear up,
> > When you check out a git branch it your working directory its hides
> > the files not in your branch.
> It does not hide anything. You can think of this as a sequence of two
> steps: a) remove all files which are in the tree referenced by the
> currently checked out commit; b) creating all the files which are in
> the tree referenced by the commit you are about to check out.
> > If you have say 3 branches and you want to check them all out
> > independently and work on them at the same time, are you allowed to
> > specify a directory name for each branch?
> > eg lets say my main reposity is at /git/repos/project1
> > Can I check out branch1, branch2 and branch3 respectively into /home/
> > myname/project1/branch1, /home/myname/project1/branch3. /home/myname/
> > project1/branch3, and work on them without interference?
> > Will issuing git commands reference the /git/repos/project1
> > transparently?
> > The working directory aspect has me confused, because it seems that
> > checking out always references, a single directory in in /get/repos/
> > directory at all times.
> "No" to all the questions above.
> Actually, it may be that you have developed an idea about a typical
> repository layout that is not supported by Git. If you're coming from
> a Subversion world this can be understandable: the directories (which
> represent everything in Subversion) found in any given revision may
> hold absolutely unrelated contents, and so checking them out into
> different local directories -- all at the same time -- has sense.
> In Git, one repository contains one logical project, and branches are
> different lines of development of *the same* code. Because of this,
> the possibility to have several working directories at the same time
> would have little sense.

If still want to work in that way, would this method suffice?

1. Copy the files for that branch into a separate folder.

2. Do all the editing, testing and compiling in that folder

3. After finishing go back to the main repository directory and make
sure the currently checkout branch is the branch I am working on.

4. Copy the files I have edited back into the main repo directory,
stage them and commit them.

Would this be equivalent?

On consideration I it looks like treating the main directory as a
remote, creating branches within it, fetching them and editing them
locally would amount to the same.

Does git allow treating a directory else where on the file system,
such as a network file share as a remote as well?
> Another point about this is that Git does everything locally:
> switching a branch is super-fast as nothing is copied from the server.
> And if you want to check out another branch while you have uncommitted
> changes on the current one, and you don't want to commit them yet, use
> `git stash` which allows you to save your "work in
> progress" (actually, any number of them) to a private area in the
> repository and then apply it back when you switched back to the
> original branch.

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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to