You have a few options for making a commit on one branch available to another -- which you choose depends on how you want your history to look, later.
- A merge will create a commit on the
release
branch that has two parents: the tip ofdevelop
and the former tip ofrelease
.release
will then have all of the work fromdevelop
andrelease
. To mergedevelop
intorelease
, make sure you have a clean working copy, and rungit checkout release
, thengit merge develop
. - You can also cherry-pick individual commits that were made from
develop
on top ofrelease
. Cherry-picking creates a new commit onrelease
that performs the exact changes that were done in a commit you name. This is useful if you've done a bunch of work ondevelop
, but you only want one or two things brought over. To cherry-pick, look atgit log
, copy the sha hash that names the commit you want, and rungit checkout release
, thengit cherry-pick <commit hash>
. - If you need to move some big range of commits from one to the other, you can use rebase --onto. It's a bit more advanced, but you can read about it if you're curious.
To answer your follow-on questions:
Nope! The general purpose of
git checkout
is to make your working copy look like a thing that you name. When you rungit checkout release
, git will change the actual files in your working copy to the state that was last committed torelease
. Checkout doesn't change existing branches. (Also, you don't need the-b
ifrelease
already exists;checkout -b
is a convenient shortcut to create and checkout a branch in one shot.)Along the same lines, to switch back, all you'd need to do is
git checkout develop
again.