On Apr 28, 2:27 am, Marek Wywiał <onj...@gmail.com> wrote:
> On 27 Kwi, 22:07, Trans <transf...@gmail.com> 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 git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to