On Apr 28, 2:27 am, Marek Wywiał <[email protected]> wrote: > On 27 Kwi, 22:07, Trans <[email protected]> wrote: > > > Perhaps someone can instruct me on the proper approach, I can't seem > > to find any specific documentation on this. > > > I recently released a version of my project, for simplicity call it > > 1.0. Then I began work on version 2.0. I realize I should have created > > a branch for it, but I didn't, I got a head of myself and did all the > > major work on master. Then I found a bug in the 1.0 release and I > > needed to go back and do maintenance release. So I checked out the 1.0 > > tag and made the fix and released 1.1. But now I am stuck. How do I > > merge my 1.1 changes back into master without dumping all my work on > > 2.0? Note 2.0 has lots of changes --modifications, file renames and > > deletes. > > Assume thah your > You can create rel branches now by: > * git checkout -b rel-1.x v1.0 > * git checkout -b rel-2.x master > > now you can: > * git checkout rel-1.x > * add some fixex, > * git commit -a -m 'FIXED: some fixes' > * git tag v1.1 > > these fixes you can merge to version 2: > * git checkout rel-2.x > * git cherry-pick -x commit_ish # commit id contain fixes for 1.x > * git commit
Thanks. Can I use 'v1.1' for the commit_ish? I was also thinking maybe I could branch master, then rename branch rel-1.1 to master, then merge the old master into the new one. Seem like it should work. Or is there an issue with that? Or is that overkill compared to using cherry-pick? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
