Say i have a master and a develop branch - develop has a lot of commits that master does not for simplicity sake:
Develop: Commit 1 Commit 2 Commit 3 Commit 4 Commit 5 Commit 6 I want to cut a new feature branch from master that does not have any of these commits in develop.
but the tricky part is that I want to merge develop into my feature from commit 3 onwards.
I could cherry pick but in reality there are many, many more commits than my simple example.
How can this be done?
You could cherry-pick:
git checkout -b newfeature master git cherry-pick commit2..develop if that syntax isn't supported directly, there, use:
git cherry-pick $(git rev-list commit2..develop) note: the first commit in the a..b range notation is not included in the list of revisions, thanks Carl
Otherwise, it looks like a case for rebase --root ... --onto. I always look up the specifics in the man page.
If commits 3-6 do not depend on commits 1-2, you can clone the branch and then use interactive rebasing to split the develop branches into two branches, so that the histories look like:
develop1: master commit1 commit2 develop2: master commit3 commit4 commit5 commit6
Then you can merge the two different branches in using merge. Otherwise, you'll have to use cherry-picking as the other answer says. This will work, but you'll lose the history of the branch relationships.
In general it makes sense to create a new branch for each specific topic that you're working on, being more on the finely grained side. Local branches are cheap, and even remote branches aren't that bad. It's a lot easier to organize your trains of thought if you're keeping things on separate branches. It also encourages you to work in a way that has you dividing your problems into independent modular pieces whenever possible, which encourages better system design, improves testability, etc.
