Branches en Git

Como me gusta probar cosas cree un branch para el tema de los moderadores. Lo que tiene de bueno hacer las cosas con branches es que nunca rompemos el repo principal (hasta que hagamos un merge), ordenamos los commits con respecto a qué pertenecen y podemos cambiar de branch tranquilamente, pasando de trabajar en una cosa a otra totalmente diferente sin que haya problemas con los archivos modificados.

Estaría bueno que para cambios importantes que incluyan muchos commits y commits de varios de nosotros usemos branches (aunque si no quieren no hay problema, yo por probar cosas que supuestamente son copadas ). Acá explica un poco como crear un branch:

https://github.com/bricoleurs/bricolage/wiki/Starting-a-Project-Branch
http://grosshat.com/bazaar/desarrollo-con-git-basado-en-branches/

Yo propongo una cosa. Tener dos branches principales. El master y una que se llame new_features. Con eso ya evitamos que pase lo de la otra vez. Es una lastima que una linea de código mal puesta meta un bug boludo en la pagina y que por un feature nuevo que no esta listo no puedamos cambiarlo.

Por otro lado si cada uno quiere tener mas branches para organizar su trabajo puede hacerlo. A mi personalmente me enredan el tema de los branches. Tener un brache para cada feature va a ser contraproducente al menos para mi.

No no, la idea del branch es separar las cosas por cambios grandes pero específicos. Cuando se hace un branch, tiene que representar un cambio específico, es decir, tener un nombre lógico con respecto a los cambios que va a hacer. De esta forma tenemos organizado el código. Igual la idea no es tener mas de uno o dos branches activos, sino si es medi oenquilombado. Pero tener un branch new features es muy poco descriptivo y perdemos datos del histórico.

Yo digo que tengamos un nuevo branch para cada feature que imaginemos que puede llevar mas de un push implementar o que puede ser discutible y trabar las cosas como el caso del carousel. Para las cosas que estamos seguros de que vamos a implementar las tiramos en el master directamente, lo mismo para arreglo de bugs urgentes, etc.

Cuanto mas usemos branches mas podemos laburar en paralelo y sin miedo a pisarnos con los demás o trabar el laburo del otro. Y además podes compartirlo con el otro (lo que no es el caso de hacer commits sin pushear, donde si podés laburar sólo pero no podés mostrarle los cambios a la otra persona sin pushearlos al repo).

Imagino que por ahí lo que te da desconfianza es el tema del merge en caso de comflictos, pero te diría que por lo que se de Git y por los comentarios que tuve eso no va a hacer ningún problema. Otro problema es que hay que aprender a usar los branches (los comandos y eso), pero por lo que estuve investigando es bastante fácil. Cualquier duda que tengas preguntame y si no lo se de última lo investigo, ya que me interesa el tema.

Mmmmm. No me parece que este conceptualmente mal ordenar los branches así. La palabra brache significa rama y new_features seria nuestra rama "inestable". Donde trabajo ordenamos los branches por versiones. 1.5, 1.6, 1.7 etc. Ninguna describe los cambios que se están haciendo adentro. Si la versión 1.5 esta en producción y se reporta un bug se repara sobre ese branche pero eso es solo la forma de trabajar que uno elija.

Si vamos a hacer un branche por cada feature deberíamos ponernos de acuerdo en que características son importantes y cuando tiempo mas o menos tardarían en llegar al master. Porque al no tener control de versiones nos van a quedar features sin desarrollar eternamente colgados . Me parece que la forma de trabajar que estas proponiendo va a requerir de mas coordinación entre nosotros.

fabian_1945 escribió:Mmmmm. No me parece que este conceptualmente mal ordenar los branches así. La palabra brache significa rama y new_features seria nuestra rama "inestable". Donde trabajo ordenamos los branches por versiones. 1.5, 1.6, 1.7 etc. Ninguna describe los cambios que se están haciendo adentro. Si la versión 1.5 esta en producción y se reporta un bug se repara sobre ese branche pero eso es solo la forma de trabajar que uno elija.

Conceptualmente el número de versión está asociado a un tag, aunque está bien tener un branch para un tag si quieren mantener el trunk limpio para arreglar posibles bugs. Pero hay lugares donde laburan TODO cambio en branches. No digo irnos a tal extremo, pero el quilombo con el carousel nos fuerza un poco a los cambios como ese a laburarlos aparte.

fabian_1945 escribió:Si vamos a hacer un branche por cada feature deberíamos ponernos de acuerdo en que características son importantes y cuando tiempo mas o menos tardarían en llegar al master. Porque al no tener control de versiones nos van a quedar features sin desarrollar eternamente colgados . Me parece que la forma de trabajar que estas proponiendo va a requerir de mas coordinación entre nosotros.

No creo que haya falta ponernos de acuerdo, las features están en GitHub y los branches visualmente también. Simplemente el que empiece a hacer un feature se la auto-asigna y así no nos pisamos, le pone el nombre del branch a uno parecido al feature de GitHub y listo. Al estar asignado otro no te va a robar el feature a menos que sepa lo que está haciendo.

Una vez que se mergea el branch con el master el branch muere o queda abandonado, creo que Git eso te lo muestra (fijate que en GitHub dice branches "activos").

Ok, ahi cree mi primer branch, se llama user_profile, yo me voy a encargar de crear la estructura de datos para soportar los datos personales del usuario, el avatar y todo lo relacionado con eso. Si queres te dejo con la parte de administración estaria bueno que los admins puedan borrar exchanges y comentarios para siempre. Osea sin la posibilidad de ser reactivados.

Ahí me hice un branch para los features de moderacion, me traje los cambios del tuyo e hice un merge con las cosas nuevas. Me aparecieron montones de conflictos porque esa rama es muy vieja y esta desactualizada. No tenemos que dejar que esas cosas pasen. Es como te dije mas arriba si quedan features colgados después lo los seguimos mas. Necesitamos ponernos de acuerdo cuanto tiempo le va a llevar a un branch nuevo unirse con el master antes de que se armen los conflictos.

Si en realidad supongo que la idea es dejar de desarrollar en el master cuando tengamos un branch, excepto para arreglar bugs de producción. Lástima, tenía la idea de que se podía avanzar en paralelo, pero me parece que sólo va a ser posible cuando no toquemos los mismos archivos.

También hay que tener en cuenta que todo lo que respecta a moderación atraviesa transversalmente a otros features. En el sentido de que un moderador puede cambiar lo que un usuario hizo en la pagina sin importar que controller o action usó. Lo que deberíamos hacer a partir de ahora es tratar de encapsular todo lo que tenga que ver con permisos y tener en cuenta estas cosas desde un principio. De otra manera el branch de moderacion siempre va a estar en conflicto con los demás.

Si mejor dedicarnos sólo a eso, para no tener problemas de merge después.

Ah una cosa, estaría bueno auditar todo lo que haga un modeardor. Es decir, crear una colección moderator_action o algo así que guarde todo lo que hace un moderador. Es posible que tengamos que en algún momento haya que moderar algún moderador descontrolado y lo mejor para esto es tener un log.

Sera que no me tenes confianza y me queres controlar

A mi me parece que en estos momentos deberiamos testear lo que tenemos ver si sirve y deployar. Porque muchas de las cosas que siguen las vamos a construir sobre esto que tenemos echo.
Sobre el daño que podrían causar me parece que somos mas vulnerables a un ataque con bots spamers que a que le demos el rango de moderador a una persona que no corresponde. En ese sentido priorizaría el poner un captcha en la registración. Si queres podemos hacer un branch para eso.

Pensa que recién estamos trabajando sobre la funcionalidad básica. La auditoría es un proceso de mejora que se inicia cuando esta todo funcionando. No lo veo prioritario en estos momentos.

Y mas teniendo backups diarios y siendo que no tenemos un numero significativo de usuarios creo que quedaría registrado al momento si es que alguno de los dos se hace el loco y toca los datos de los usuarios.