Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

Problem: I need somehow to checkout an existing branch of a project that is already cloned locally on my file system without being in that particular folder of this project.

Solution: I'm trying to do the following:

  • git clone 'github-project-url' 'file-system-folder'
  • git checkout 'existing-branch' 'file-system-folder'
  • I do realize that second step is not quite right, but I also am trying to avoid to cd 'file-system-folder' .

    Why are you trying to avoid the cd ? This could affect the kinds of answers that would work for you. Anonymoose May 20, 2011 at 14:39 I can't speak for the asker, but we are unable to perform a cd because we do not wish to run a sub shell when executing the checkout command. That said, I do agree that is the clearest approach if a sub shell is available. michael Oct 28, 2019 at 23:46

    You can use --git-dir to specify the .git directory to use as the repository, and --work-tree to specify the working tree to to the checkout in. See the git man page for details.

    git --git-dir=file-system-folder/.git --work-tree=file-system-folder checkout existing-branch
                    +1: Certainly the best in terms of the OP's preferences, though if you happen to be looking for the shortest way to do it instead of the fewest commands, cd in a subshell is really quite nice.
    – Cascabel
                    May 20, 2011 at 16:06
    

    Since Git version 1.8.5, you can also use -C <path> option. Be sure to use it before any other command:

    git -C ~/my-git-repo checkout master

    Note that it doesn't have to be specifically the .git folder. Here is the man documenation:

    -C <path>
           Run as if git was started in <path> instead of the current 
           working directory. When multiple -C options are given, each
           subsequent non-absolute -C <path> is interpreted relative to
           the preceding -C <path>.
           This option affects options that expect path name like --git-dir
           and --work-tree in that their interpretations of the path names
           would be made relative to the working directory caused by the -C option.
           For example the following invocations are equivalent:
               git --git-dir=a.git --work-tree=b -C c status
               git --git-dir=c/a.git --work-tree=c/b status
                    Did you actually do this?  I don't see your code example working on my pc, nor does it look like the example you showed (which has --git-dir and --work-tree.
    – Keith
                    Sep 26, 2017 at 21:24
                    Yep I've used like so  with tons of different got commands. git clone $ACQUIA_REPO ~/acquia; git -C ~/acquia checkout -b $CIRCLE_BRANCH; git -C ~/acquia log; git -C ~/acquia add .; git -C ~/acquia commit -am "$( cat
    – General Redneck
                    Jan 7, 2018 at 2:35
                    The man page has git-dir and work-tree. To simply perform a git command on a git repo with a .git folder -C is all you need.
    – General Redneck
                    Jan 7, 2018 at 2:44
                    This won't work. --git-dir needs the actual .git directory; and this will do the checkout in the current working directory, not in the repository. You need to pass both --git-dir and --work-tree.
    – Brian Campbell
                    May 20, 2011 at 14:49
                    Also it seems to me during testing that you must pass those flags to git itself, and not the checkout subcommand.
    – Victor Zamanian
                    May 20, 2011 at 14:55
    

    You're quite welcome to use --git-dir and --work-tree to avoid cd'ing, but honestly, it's easier just to cd. To avoid having to cd back, you can do it in a subshell:

    git clone foo foo-copy
    (cd foo-copy && git checkout branch)
    

    Of course, in this specific case, you don't actually need two commands:

    git clone -b <branch-to-checkout> foo foo-copy 
                    Well, when you create a command line script, it's not easier ;) Anyway thank you for your feedback!
    – eistrati
                    May 20, 2011 at 15:18
                    Um, eistrati, anything you can type at the shell prompt, you can put in a script! What's the problem?
    – Robin Green
                    May 20, 2011 at 15:20
                    No problem, just why would I do 3 operations (cd folder && git checkout && cd back) when I can do only one (git checkout with specified options)?
    – eistrati
                    May 20, 2011 at 15:30
                    @eistrati: You're of course free to write your scripts however you want, but more commands of shorter total length is not really more to handle, and if others are working on your scripts, you might find that they too disagree with you. (cd <dir> && ...) is a very, very common and well-understood idiom.
    – Cascabel
                    May 20, 2011 at 16:05
                    In addition, the semantics of --git-dir and --work-tree are really non-obvious.  If you want to use them and avoid unpleasant surprises, always set both of them, and only use absolute paths.  @Jefromi's advice (to avoid those issues completely) is very sound in my experience.
    – Mark Longair
                    May 20, 2011 at 17:07
    

    git 2.5 added the ability to have multiple working trees using git worktree. So this case, you'd use something like

    git worktree add -b new-branch-name ../dir-name existing-branch

    you can then change to dir-name and make your commits as usual. The commits will end up in your original repository (where you used worktree add).

    When you're done and everything you want is committed, you can delete the dir-name folder and run git worktree prune to clean up the orphaned worktree in your repo.

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question. Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers.