El mié, 29 feb 2012, Tio Oscar decía: > El día 29 de febrero de 2012 11:43, Fernando Toledo > <[email protected]> escribió: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > El 27/02/12 21:45, Ariel Camino escribió: > >> El 27/02/12 15:58, OSiUX escribió: > >>>> Ya que aca varios usan git... tengo una duda, supongamos que > >>>> estoy en el desarrollo de un software y quiero hacer la > >>>> version 2 sin reescribir por completo el codigo, osea dentro > >>>> del mismo arbol de desarrollo. > >>>> > >>>> Se que para versiones intermedias se pueden usar tags, onda de > >>>> tal tag marca la 1.4, el tema es, que tengo que seguir > >>>> manteniendo la version anterior. se que con los branches puedo > >>>> tener una rama de desarollo mientras dejo la master limpia > >>>> para resolver bugs o demas, que es lo que actualmente hago, > >>>> pero la finalidad siempre es la de mergear con master y aplicar > >>>> esos cambios, aca estoy hablando de mantener 2 versiones al > >>>> mismo tiempo, la 1.x y la 2.x > >>>> > >>>> No lei muhco hacerca de los tags, pero queria saber si se > >>>> puede hacer como los branches, onda tagear una revision como la > >>>> 1.x, otra como la 2.x y volver cuando lo neceseite a la 1.x > >>>> modificar comitiar pushear y despues volver a master o a la > >>>> 2.x... se puede? > >>>> > >>>> Como lo hacen ustedes? > >>> > >>> Te paso una muy buena guía a seguir: > >>> > >>> - http://nvie.com/posts/a-successful-git-branching-model/? - > >>> http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf > >>> > >> > >> Yo uso (o intento usar) ese esquema con git flow, que me simplifica > >> bastante la vida. > >> > >> Desde mi punto de vista, si hay una versión anterior, que queres > >> seguir manteniendo (por ejemplo 1.x) y que además esos cambios no > >> queres que se mergeen luego con tu HEAD de develop, master, etc, > >> para mí, la solución es tener dos repositorios diferentes. > >> > >> Por ejemplo, usando git flow, yo tengo dos releases v1.0 y v2.0, > >> hago un: > >> > >> acamino@athos:~/trabajo/pruebas$ git tag v1.0 v2.0 > >> > >> y luego intento crear un feature nuevo basado el release v1.0: > >> > >> git flow feature start un_re_feature v1.0 > >> > >> si bien se "basa" en la versión 1.0, una vez terminado hace un > >> merge contra el HEAD de develop (es decir lo que tenes en tu > >> versión 2.0). > >> > >> Por eso me parece que la posta es tener un repo distinto por cada > >> "major release", lo cual desde mi punto de vista es bastante > >> lógico, porque estás teniendo dos versiones de un mismo software > >> que van perdiendo la relación entre sí (no te interesa que los > >> cambios a una se apliquen a la otra y viceversa). > >> > >> Aunque me gustaría preguntarle esto a algún capo gitero, hay una > >> lista de git argentina "git-ar", estaría bueno que preguntes por > >> ahí. > >> > >> Salutes! > > no hace falta crear otro repo, podes crear un branch huerfano: > > git branch --orphan version-2.0 > > > > > > - -- > > Fernando Toledo > > Puedo preguntar que seria un branch huerfano?
Lista GIT Argentina: [email protected] -- :: Osiris Alejandro Gomez (OSiUX) [email protected] AA70 93FD B6EF EB42 6920 7530 A799 B226 74C8 A3FE http://osiux.com http://wiki.buenosaireslibre.org
signature.asc
Description: Digital signature
Lanux - Grupo de usuarios de GNU/Linux de Lanus Visitanos en: http://www.lanux.org.ar Reglas de etiqueta para el posteo de mensajes a la lista: http://www.lanux.org.ar/?page_id=35 Articulos y noticias por rss: http://www.lanux.org.ar/?feed=rss2 Lanux por irc: irc.freenode.net -> #lanux. _______________________________________________ General mailing list [email protected] http://listas.lanux.org.ar/cgi-bin/mailman/listinfo/general
