1

I'm doing something similar to this question where I have a Boilerplate Github repository which I will use to start new projects with. The difference is that I will sometimes want to add features from one of the cloned projects back into the boilerplate and push changes from the boilerplate into the projects.

As they are all my own repositories, I'm using this technique to clone the repo's instead of forking and add an upstream to the boilerplate remote so I can pull changes from there.

$ git clone git@github.com:YOURNAME/foo.git bar
$ cd bar
$ vim .git/config
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = git@github.com:YOURNAME/bar.git #replace foo with bar
$ git remote add upstream git@github.com:YOURNAME/foo.git
$ git push -u origin master

Because the projects will take a life of their own, I will only want to pull parts of the boilerplate down to the projects as I add new features in the boilerplate. Is this where I should use a git cherry-pick as described here?

Going back the other way. I'm guessing I should create a feature branch in the project. Once I'm happy with it, and before I merge it back in, I should git cherry-pick from the project branch back into the boilerplate? Or should I do a pull request from the project to the boilerplate?

sansSpoon
  • 2,115
  • 2
  • 24
  • 43

1 Answers1

0

If you just want to apply commits to unrelated branches (meaning branches which are never merged together), then cherry-picking (including for multiple commits in one command) is the proper way to duplicate said commits across repos.

And that is what cherry-pick duplicates a commit.
It works only if those commits don't depend on previous commits content, ie if they don't have functional dependencies based on previous commits (of the branch tou are cherry-picking from).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250