On 28 Kwi, 17:55, Trans <[email protected]> wrote: > 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? Yes, you can use tags or branch names as 'aliases' to ish (simplify).
> > 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? if you have fixes in one commit, cherry pick is good f.e. you develop all fix on separate branch, and then you can merge it by switch to targat branch and do: * git merge --squash B1234-some-bug * git commit in other way if you made some commits in branch 1.x you can just merge them to 2.x or some other branch. In our company we are using branches like: * rel-1.1 * rel-1.2 without master, and for features/bugs we are using separate branches merged by --squash to branch and chery picking to other branches if we need. so, you can use merge or cherry-pick, it depends on your favourite workflow :) > > -- > 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 > athttp://groups.google.com/group/git-users?hl=en. -- 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.
