Branches aislados en git

[Normando Hall]

Saludos lista.

Pregunta de novato. tengo un repo local, y al cual le he creado varias ramas a partir de master. Si cambio a una rama y realizo cambios sin confirmarlos, y luego vuelvo a la rama master, veo el archivo modificado de la rama en la que estaba antes.

Por lo tanto, como leí en stackoverflow, los únicos cambios aislados son los cambios confirmados http://stackoverflow.com/questions/6551604/git-branches-should-isolate-the-changes-or-should-not

El punto es que es un dolor de huevos trabajar asi. Supongamos que tengo master, rama1 y rama2. Hago cambios en rama1 y no los confirmo. Luego paso a rama2, hago otros cambios en otros archivos, luego un add . y finalmente un commit. En este commit se llevará tanto los cambios hechos en rama2 como en rama1, con la consiguiente confusión a futuro sobre en cuál rama fueron modificados determinados archivos y con qué finalidad.

Mi pregunta concretas es si hay alguna forma mejor de trabajar, o necesito indefectiblemente clonar varias veces el mismo repo para poder trabajar de manera "aislada"?

Sino la única que queda es hace un stash cada vez que cambio de rama.

Escucho sugerencias.

Normando

--

	Normando Hall CTO (0341) 155-852144 · norman...@dvision.com.ar dVision S.A. Av. Belgrano 929 - Rosario - Argentina Te: (0341) 424-1302 in...@dvision.com.ar · dvision.com.ar Tecnología en manos creativas
No me imprimas si no es necesario. Protejamos el medio ambiente Este mensaje y todos los archivos adjuntos son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por ley. Si usted recibió este mensaje erróneamente, por favor notifíquenos respondiendo al remitente, borre el mensaje original y destruya las copias (impresas o grabadas en cualquier medio) que pueda haber realizado del mismo. This message and any attachments are for exclusive usage of an addressee and may contain confidential or privileged information whose disclosure is subject to penalty by law. If you are not the addressee, please notify the sender by return e-mail, delete the original message and destroy any existing copy no matter if printed or recorded.

[Fernando Carril]

Googlea gitflow, yo lo implemente en el laburo con equipos distribuidos y va muy bien.
En gral no usas master excepto para hotfix y releases. Haces un branch de desarrollo del que podes hacer integración continua y cada desarrollo es un feature branch.
Los cambios parciales los vas commiteando. Por mas que sean muchos después quedan como un merge en la rama de desarrollo y el featurebranch lo matas. También podes ir haciendo amend pero no suma mucho.

--
--
-------------------------------------------------------------------
Para obtener más opciones, visita este grupo en
http://groups.google.com/group/webandbeer?hl=es.
El blog del grupo
http://www.webandbeer.com.ar
---
Has recibido este mensaje porque estás suscrito al grupo "webandbeer" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a webandbeer+...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Demián Andrés Rodriguez]

Para aislar cambios sin hacer commit solo te queda hacer un git stash...

Como dice fernando, la forma correcta para laburar sería crear un branch a partir de master, hacer varios commits, testear los cambios y luego mergear tu branch a master.

Si hay mas gente laburando en master deberías mergeartelo a tu branch a diario para evitar conflictos y mantenerlo actualizado.

Al menos ese es el workflow que usamos en mi laburo. Tenemos main branches: stable, beta, alpha y master.

[Normando Hall]

Así hago, uso el esquema de gitflow pero manual, sin la extensión gitflow.

El punto es que uno está modificando archivos y no necesariamente hay que hacer un commit porque no está finalizado, y al cambiar de branch lamentablemente esos archivos modificados lo siguen estando en cualquier branch, hasta tanto se comitee.

El esquema presentado por gitflow es fantástico. El punto es el de la aislación, y ello no ocurre en git, ya que un branch = apuntador de confirmaciones.

Es una pena que sea así. Por ejemplo si yo estoy laburando con 5 features al mismo tiempo en mi repo local, en 5 ramas respectivamente, cuando en una intento hacer un commit, no puedo distinguir de qué branch provienen cada una de las modificaciones. Quizás hay algo que no entiendo, pero creo que es así, y no hay mucha forma de hacer algo distinto, no?

Saludos y gracias por las respuestas.

[Tio Oscar]

Una par de cosas, sumo mis porotos a usar git-flow, que es una extensión de git extremadamente útil. Esta te ayuda a seguir el work flow de master/develop y las ramas de releases/features/hotfixes. Tardás 1 semana maximo en acostumbrarte y no volves a trabajar de otra manera núnca mas.

Por otro lado, no tengas miedo de forkear, es algo también bastante útil, las herramientas de mergeo y diff de git son expectaculares.

Para entender git-flow y el workflow recomendado en 5 minutos te recomiendo entrar aca:

https://danielkummer.github.io/git-flow-cheatsheet/

Nunca desarrolles en master, siempre en develop y cuando tengas que hacer un feature, no importa lo simple que sea, crea una rama aparte y después mergeala con develop, nunca mas vas a preocuparte de que cambio era de que cosa ni nunca mas vas a comentar código (bloques de código digo, comentar es una buena idea).

Lo que propone Demian no te lo recomiendo (perdon Demian :P) pero si seguís el otro workflow, solo te tenes que preocupar de mantener "actualizada" la rama develop y los releases (alpha, beta, etc) lo manejas en ramas apartes.

Otra cosa que te recomiendo seguir, es semver (versionado semántico):

http://semver.org/lang/es/

Exos ~ Programador, hacker y filósofo
web: http://blog.exodica.com.ar
Linked'in: http://www.linkedin.com/in/ogexos
Twitter: @exos, Indeti.ca: @exos
Tels: [+54 11] 6385-EXOS (3967) - [+54 9 11] 6133-2442

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d-- s++:* a- C+++$ UBL+++$ P(-) L+++$ !E--- W+++$ !N !o K-? !w--- !O !M-- V? PS+++@ !PE Y+(++) PGP++ !t--- !5 X++ R(+) tv--(!) b- DI D-- G e@ h>++ r--- y*>+++++
------END GEEK CODE BLOCK------

[Tio Oscar]

El 25 de junio de 2014, 0:10, Normando Hall <norman...@gmail.com> escribió:

Así hago, uso el esquema de gitflow pero manual, sin la extensión gitflow.

No lo dudes, usa git-flow, lo vas a amar.

 

El punto es que uno está modificando archivos y no necesariamente hay que hacer un commit porque no está finalizado, y al cambiar de branch lamentablemente esos archivos modificados lo siguen estando en cualquier branch, hasta tanto se comitee.

Justamente la ventaja de tener features branches, es que un commit no termina nada, sino que se termina cuando se mergea con develop, de hecho es recomendable hacer commits simples, onda "agregue parametro de configuracion", "agregué método tal", etc...

 

El esquema presentado por gitflow es fantástico. El punto es el de la aislación, y ello no ocurre en git, ya que un branch = apuntador de confirmaciones.

No se si entendí bien, pero el esquema de gitflow justamente te evita problemas, por ejemplo, una vez terminada una roadmap, podes crear una branch release, y seguir laburando/rompiendo sobre develop, y solo mergear bug fixes.

 

Es una pena que sea así. Por ejemplo si yo estoy laburando con 5 features al mismo tiempo en mi repo local, en 5 ramas respectivamente, cuando en una intento hacer un commit, no puedo distinguir de qué branch provienen cada una de las modificaciones. Quizás hay algo que no entiendo, pero creo que es así, y no hay mucha forma de hacer algo distinto, no?

Justamente, 5 features son 5 ramas diferentes, y cada vez que terminas una se mergea a develop, asi que siempre vas a saber de donde vienen esos cambios, una forma que hay tambien de laburar, es por ejemplo poner un prefijo que identifique la feature en cada commit, por ejemplo "#454: Agrego metodo tal...".

 

Igualmente sos libre siempre de mergear develop o ramas de features con otras features. Si por ejemplo haces algo en la feature #543 y necesitas esos cambios en la feature #544, simplemente haces un "git merge feature/#543 sobre la branch feature/#544 y listo.

Saludos y gracias por las respuestas.

[Tio Oscar]

[Javier Alvarez]

No tengo tanta experiencia con git, y no termino de entender cual sería la desventaja de ir haciendo commits aunque la feature no este completa. O, de última, hacer algo asi: http://stackoverflow.com/questions/927358/undo-the-last-git-commit o usar amend.

--

--
-------------------------------------------------------------------
Para obtener más opciones, visita este grupo en
http://groups.google.com/group/webandbeer?hl=es.
El blog del grupo
http://www.webandbeer.com.ar
---
Has recibido este mensaje porque estás suscrito al grupo "webandbeer" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a webandbeer+...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Javier Alejandro Alvarez

Follow me: @neiker

[Normando Hall]

Si, evidentemente para que funcione la cosa es hacer commits de pequeñas cosas, no esperar hasta que esté un poco mas completa la feature.

Concuerdo con el modelo presentado en git-flow, es muy bueno, pero es sólo una modalidad, y lo que yo preguntaba es inherente git en si mismo, aunque la modalidad usada sea git-flow o cualquiera.

Bueno, ya me van quedando claras alguna cosas, como commitear permanentemente, especialmente cuando conmuto a otro branch, para no mezclar los archivos modificados de una rama en otra.

Gracias gente por los aportes.

--