git: put a branch in a subdirectory

I have a git repository (at github.com) with two branches: master and gh-pages. I would like to have the gh-pages branch in a subdirectory, so that I don’t need to switch branches every time.

repo/
    (content of the master branch)
    gh-pages/
            (content of the gh-pages branch)

Is that possible ?

  • Git: How to ensure new branch is based on upstream master
  • svn copy command
  • Commit a change to more than one branch in Git
  • Using feature, story and task branches?
  • Scare of My Life With GIT: I've got no branch!
  • Git - Create a new remote branch out of an old commit
  • Pass “file name” from a text file to a command line where each line of a file is file name
  • Calculating total lines added/deleted after a merge?
  • git clone with http not working in gitlab
  • Unable to release Jenkins plugin to jenkins-ci.org
  • Create a new localhost Git repository from already cloned Git?
  • Does SVN have an equivalent to git's commit (without the push)?
  • 6 Solutions collect form web for “git: put a branch in a subdirectory”

    That’s not how things are designed to work. You could theoretically clone the repository within a subdirectory of your original clone and mark that directory as excluded from the higher level repository, but wouldn’t it be much simpler to just check it out in a completely different directory instead of a subdirectory?

    That is to say…

    /repo/master/(clone on master branch)
    

    and then another clone that’s on the other branch

    /repo/gh-pages/(clone on gh-pages branch)
    

    You may be looking for the subtree merging option.

    It will let you checkout an unrelated branch into a subdirectory of another and then merge back and forth between them. You would still have to checkout gh-pages and merge in changes from the main repo before pushes would go live on GitHub, however.

    You could also check gh-pages out as a submodule of your master branch if that suits you better.

    Generally with version control it’s not a good idea to combine multiple projects into a single repository. For instance, what if someone would like to fork your repository, but not host their copy at GitHub? Then the gh-pages directory would be completely useless to them. Even if they did host theirs at GitHub, the gh-pages directory could very well still be irrelevant to them.

    I realize that the GitHub way of doing this goes against this advice, somewhat (after all, even though they are on different branches, they’re still in the same repo). However, the branches in this case are completely unrelated (they don’t share any history) so from a practical perspective, it’s as if they were in separate repositories. If someone clones your repo and doesn’t want the gh-pages branch, they can delete it and it will have zero effect on master.

    Starting with git 2.5, you can have both branches checked out at the same time in different directories. See https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows. Setup via git worktree add -b gh-pages ../gh-pages origin/gh-pages.

    If you want to have the content of a subdirectory of your master checkout to be put into gh-pages on github, use the script provided at https://github.com/X1011/git-directory-deploy.

    I’ve tried the git subtree trick, but it requires that master have all the gh-pages content committed to it, which is not ideal in this case. Much better and simpler is to

    1. Create a new directory at ./repo/gh-pages/
    2. Put a line on .gitignore for that (gh-pages)
    3. cd gh-pages/, git init and git checkout -b gh-pages, creating an independent git remote there

    You can also git clone directly to ./gh-pages/ with only the branch you want.

    Branches in git are pointers to commits (that move), and so having a branch as a subdirectory is not possible.

    To be fair, git co gh-pages is not much harder than cd ../gh-pages

    Git Baby is a git and github fan, let's start git clone.