Working with subtrees in a second working copy

Suppose we have two developers. One developer added a subtree to the “main” git repository at foo/bar/ path (foo/ is a normal directory and foo/bar/ now is connected as a subtree to a separate “subtree” repository). The second developer pulled changes and got foo/bar/. However at his working copy foo/bar/ is not a subtree to git, it is just a directory in the main repository.

Now the second developer got the task to switch that subtree to a newer tag in the subtree repository. He thinks he can pull from the subtree repository using git subtree pull but than he needs to add a substree first. But git subtree add in his working copy does not work because the directory already exist. In his working copy this directory does not look like a subtree to git.


  • How can the second developer tell git that foo/bar/ is actually a subtree?
  • How can he checkout a tag for this subtree?

  • Possible workflow with git submodules
  • Git Subtree Specific Ignoring
  • git subtree/submodule a file from a repository and update it
  • Git - deploy dist folder to different remote
  • git subtree error “fatal: refusing to merge unrelated histories”
  • How to figure out a working copy contains a subtree?
  • How to remove previously added git subtree and its history
  • How to make an existing subdir as subtree for another git repo, with squashed commit?
  • 2 Solutions collect form web for “Working with subtrees in a second working copy”

    I don’t believe subtree has any built-in method to let the second developer know a subdirectory is actually a git subtree. The best way to indicate that may be with a file in the root of the subtree (which is not ideal I’ll admit).

    The second developer in your example, shouldn’t have to do a git subtree add though. They should only have to do a pull followed by a push (again, they’ll need some other way of knowing where it all came from).

    To update the subtree, the second developer would:
    (NOTE: I’m new to subtree, so take this for what it’s worth)

    1. Make their changes as usual
    2. Commit their changes to the ‘main’ repository
    3. Push their changes to the ‘main’ repository
    4. Do a pull from the subtree: git subtree pull --prefix=bar ../bar.git master
    5. Do a push to get their changes in the subtree: git subtree push --prefix=bar ../bar.git master

    The whole point of subtrees (in contrast to submodules) is that they do not look like repositories and do not need any configuration files. git-subtree encodes all required information for subsequent merges in the initial merge commit, using a “git-subtree-” prefix, so there really is no difference between the two developers’ working copies in your example. Both will equally be able to git subtree pull ....

    If you want to have explicit (i.e. recognizable) sub-repositories that can be easily updated from upstream, use git submodule.

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