I have a feature branch that has too many features in it!
For example, say we have the branch foo that has spanned too many files and items to really be just one feature.
Master ---A---B---C
\
foo E---F---G---H
commit E and F have to do with each other, commits G and H are totally different. I should have checkout to master, then started another branch for G and H.
How would I move those commits to a new branch? This would leave commits E and F on branch foo, and commits G and H on a new branch bar with the same parent commit C that foo is based off.
Master ---A---B---C
|\
Foo | E---F
|
Bar G---H
If none of the code changes are shared between the two features, you can checkout master (or C), make a new feature branch, then cherry-pick G and H (using the commit shas).
If they do depend on some changes from the other feature (E and F) it might be less work to treat F as a "feature trunk" and split again (so, have two feature branches that merge back to the trunk feature branch and then back to master eventually).
If they're really completely unrelated work that will ship separately, but the G-H feature does depend on a few changes from the E-F feature, it will probably be worth the work to use the former approach (cherry-pick) and just manually backport any changes you might need, and deal with potential conflicts from whichever branch gets merged last, when they come up.
There's a very handy guide to cherry-pick over here, including some nice graphs.