`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.

▲ jolmg 2 hours ago | parent | next [-]

Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the changes of the other PR so they should review that one first. Should they want to add changes to the first feature, they just need to checkout that branch, do the changes, and merge to the second feature branch so they're available there.

▲ catlifeonmars 4 hours ago | parent | prev [-]

What does it mean to split a branch in two?

	▲	rmunn 3 hours ago \| parent [-]
		Probably to take a series of commits and decide "this one goes on branch A, this one on branch B", e.g. if you intermingled fixing bug A and B in the same branch, you could more easily go through and assign each commit to a new branch. The existing workflow for that would be (there are several possible workflows, but this is what I would do): `git checkout intermingled-branch git branch bugfix-A git branch bugfix-B git checkout bugfix-A git rebase -i # Edit the file, keep commits that fix bug A, drop commits that fix bug B git push origin bugfix-A:bugfix-A git checkout bugfix-B git rebase -i # Edit the file, keep commits that fix bug B, drop commits that fix bug A git push origin bugfix-B:bugfix-B`