How to pull in changes from skeleton sub-repository into production super-repository

I am using the Aurelia skeleton which contains various project setups for different purposes, but it is more of a general question of how you would do something with git like discribed below.

I would like to be able to merge in the updates published in the GitHub skeleton repository to the project I am actually working on. How would you do that?

  • Should I exclude Aurelia scripts folder in .gitignore?
  • NPM update error - Fails to execute GIT
  • Add 'scripts' folder to .gitignore in Aurelia project?
  • How to deploy Aurelia to GitHub Pages (gh-pages)
  • Error not found Git - trying Aurelia.js
  • At the moment I just initialized a new local repository in the skeleton-typescript project (which I am using) and connected it to a private remote repo to push my changes. But with this setup, I am polluting the parent repository (remote pointing to aurelia-skeleton on Github) with my project-specific changes.

    It would be perfect to have some kind of one-way tracking going as the aurelia-skeleton remote repository is normally only used to pull changes in.

    As a second step, it would be interesting how you could create a pull request with such a setup. In this case, I would like to use the changes I made in the sub-repository to be merged into the fork of the aurelia remote…

  • git log <since> <until> shows all log instead of specified
  • Syncing between perforce and git
  • Error when running git pull origin master
  • How to delete a branch and all the objects it referenced
  • How to compare 10 big XML files?
  • How to make git automatically load previous comment in editor on commit?
  • One Solution collect form web for “How to pull in changes from skeleton sub-repository into production super-repository”

    My usual workflow is to create a dedicated branch from which to track the upstream project. You can cherry pick what you want onto that branch and create a pull request without muddying the template with your project specifics.

    First thing, go ahead and fork aurelia/skeleton-navigation so you can easily issue a pull request through Github’s GUI.

    Clone your fork of the project with remote named upstream in a new folder called skeleton-typescript

    git clone -o upstream skeleton-typescript
    cd skeleton-typescript

    Rename master branch.

    git branch -m asmaster

    Create a new repository for skeleton-typescript

    Tip: You can do this right from the command line using Github’s API with something like curl

    curl --data '{"name":"skeleton-typescript"}' -u YOUR_GITHUB_USERNAME

    Add the remote.

    git remote add origin

    Split the repo into a subtree (see source code for man page) which will contain a new tree with all the commit history of files in the prefix directory.

    git subtree split --prefix=skeleton-typescript

    This will print out a single commit ID which is the HEAD of the subtree.


    Create your master branch from that commit.

    git checkout -b master 539d913a8cf9b34b644273b5cdb480359553247c

    Push to and track your new repo.

    git push -u origin master


    Commit some work on skeleton-typescript

    echo "notable contribution" >> file.txt
    git add .
    git commit -m "backport test commit"
    git push origin master

    Checkout the upstream super-project branch, and cherry-pick the subtree commits.

    git checkout asmaster
    git cherry-pick -x --strategy=subtree master
    git push upstream asmaster:master

    Now you can issue a pull request from your upstream fork YOUR_GITHUB_USERNAME/skeleton-navigation:master branch to their aurelia/skeleton-navigation:master branch.


    Now there’s going to be updates no doubt to your upstream’s upstream (aurelia/skeleton-navigation:master) which will include updates to your subtree’s skeleton-typescript folder.

    Add another remote to track the original project.

    git remote add upupstream

    Note that you now have 3 remotes in your local repository.

    git remote -v
    origin (fetch)
    origin (push)
    upstream (fetch)
    upstream (push)
    upupstream (fetch)
    upupstream (push)

    Pull down updates.

    git checkout asmaster
    git pull upupstream master

    Split off the subtree again and grab the HEAD commit.

    git subtree split --prefix=skeleton-typescript


    Switch back to subproject.

    git checkout master

    If you have never backported changes, then a notable attribute of git subtree split is that you’ll have the exact same hash commit history, so you can fast forward merges without rewriting history. From the docs:

    Repeated splits of exactly the same history are guaranteed to be identical (i.e. to produce the same commit ids). Because of this, if you add new commits and then re-split, the new commits will be attached as commits on top of the history you generated last time, so git merge and friends will work as expected.

    git merge 095c0c9f7ed06726e9413030eca4050a969ad0af

    However, if you have already backported cherry-picked updates, or any other changes to the subtree history, then you’ll want to rebase changes, otherwise you’ll have duplicate commits.

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