search

genbetadev / Genbeta-Dev-Engine

Desarrollo de un Game Engine básico sobre C++ y SFML 2.1
MIT License
63 stars 32 forks source link

Organización de ramas del repo #59

Open rickyah opened 10 years ago

rickyah commented 10 years ago

Me he fijado en que no hay una estructura de ramas creada.

Una manera de organizar las ramas sería el definido por git-flow: http://nvie.com/posts/a-successful-git-branching-model/

Resumen git-flow

Git-flow es quizá demasiad para lo que tenemos ahora mismo, un resumen de lo que considero deberíamos tener como ramas básicas para trabajar:

Una feature branch es una rama que contiene sólo los cambios para una única feature. Por ejemplo en este proyecto, una feature branch se crearía para hacer el log, o el scene manager. Una feature branch siempre sale de develop. Cuando se ha terminado la feature y está lista para mergear, tiene que estar siempre actualizado con la versión actual de develop. Eso significa que por lo general antes de hacer el PR de la feature, habrá que hacer un rebase de develop para que esté al día.

¿Opiniones?

ficion commented 10 years ago

Git-flow me parece un buen ejemplo, no sé si podría ir tan bien con este proyecto: es un grupo pequeño y la mayor parte de nosotros somos inexpertos; git-flow es como para un grupo de desarrollo más grande y serio.

Yo propongo un ejemplo más simple:

La rama master va para todo el desarrollo y se usan tags para marcar las versiones; no existe rama develop. Esto porque:

  1. Muchos se confundirán en qué rama va todo el desarrollo, dado que muchos ni siquiera entienden más de Git que los comandos pull, clone y push, puede dificultarles al principio.
  2. Éste no es un motor tan serio, con versiones cada cierto tiempo, metas y fechas fijas que seguir y testeo riguroso; es mucho más libre, prima más la experimentación para aprender. Aunque es cierto que hay metas (como la milestone 0.1 que hay) estas pueden ser marcadas con tags.

Ahora, cuando se quieran hacer cambios en paralelo del desarrollo en master (lo cuál será bastante común cuando se quieran hacer cambios grandes), tenemos los forks que cada uno de nosotros puede hacer y que siempre van al paralelo. Esto es importante tomar en cuenta, porque Git-flow está pensado para un equipo en el que todos tienen derecho a hacer commit al repositorio principal; aquí todos hacen pull-request.

Si se quisieran hacer ramas alternativas para cambios más grandes en el repositorio principal, se puede crear una rama con nombre issue-xxxx, donde xxxx es el nombre del issue en la sección de Issues de este proyecto. La rama debe terminarse y unirse (o no unirse, según el caso) tan pronto como la feature o fix pueda ser aplicado sin problemas.

Bueno, esa es mi idea.

rickyah commented 10 years ago

Para eso vale más tener la rama develop. Todo el mundo tira con esa rama, y a master sólo van los merges que los hará @adrigm, así que la rama master solo la toca el que hace merge o el que tagea versiones. Todo el resto de contribuidores está usando la rama develop, por lo que no hay nada de confusión.

Esto es por que al separar la funcionalidad en feature branches, al hacer el merge eso queda registrado en la rama master, por lo que la historia queda muy limpia.

git-flow no está pensado para equipos grandes, ni sólo para gente con permisos para el repo principal, es una forma de organizar las cosas. Yo lo he usado en equipos de una y dos personas sin problemas, con permisos y sin permisos a repo principal. Es más, incluso con permisos de escritura en un repo, tenemos la norma no escrita de no hacer un merge directo a una rama principal: siempre hay que hacer un PR para que quede registrado en la historia.

Por último, precisamente por que esto es un lugar para aprender, la gente novata puede aprender cómo se hacen las cosas en la vida real. git-flow se empieza a extender, tanto que tienes extensiones a git para usarlo (https://github.com/nvie/gitflow), y SourceTree, por ejemplo, tiene soporte directo para esas herramientas.

adrigm commented 10 years ago

Yo también voto por el uso de la rama develop, pero estamos en una fase tan temprana de desarrollo que ahora mismo no sé si merece la pena. Claro que cuanto antes se empiece con el hábito mejor.

ficion commented 10 years ago

Yo igual pienso que la rama develop facilita muchas cosas. Pero, de nuevo, es bueno que haya oportunidades para aprender, pero si te fijas, ya hay bastantes cosas de las que alguien nuevo tiene que preocuparse sólo para que pueda mirar y testear el código sin hacer cambios, lo digo por hacerles la vida un poco más fáciles; quizá esté exagerando en todo caso. Bueno, en todo caso, si se aplica la rama develop ayudaría enormemente en el futuro, como dice @adrigm.

No lo sé la verdad.

rickyah commented 10 years ago

Alguien nuevo totalmente a git simplemente tiene que saber que hay que usar develop para desarrollar, no lo veo tan complejo

Gotchamoh commented 10 years ago

Yo soy totalmente nuevo, hace muchos años que no veo C++ y de Git no tenia idea pero me gustaría aprender a usar la rama develop si creen que no es muy complicado.

2013/11/10 Ricardo Amores Hernández notifications@github.com

Alguien nuevo totalmente a git simplemente tiene que saber que hay que usar develop para desarrollar, no lo veo tan complejo

— Reply to this email directly or view it on GitHubhttps://github.com/genbetadev/Genbeta-Dev-Engine/issues/59#issuecomment-28162820 .

Mario Albornoz.

ficion commented 10 years ago

@Gotchamoh Simplemente significa que habrá dos ramas principales: master y develeop. En develop se hace todo el desarrollo normal, los cambios que pueden ser rápidos y sin testear, el resultado de temas tratados en Issue, etc; es una rama muy activa. Mientras que la rama master es mucho menos activa y recibe commits sólo cuando se hacen cambios de versión del GDE.

Gotchamoh commented 10 years ago

No suena para nada complicado, y si estamos aquí para aprender creo que se debería utilizar. Veamos que opinan los demás.

El 10 de noviembre de 2013 22:49, Ficion notifications@github.comescribió:

@Gotchamoh https://github.com/Gotchamoh Simplemente significa que habrá dos ramas principales: master y develeop. En develop se hace todo el desarrollo normal, los cambios que pueden ser rápidos y sin testear, el resultado de temas tratados en Issue, etc; es una rama muy activa. Mientras que la rama master es mucho menos activa y recibe commits sólo cuando se hacen cambios de versión del GDE.

— Reply to this email directly or view it on GitHubhttps://github.com/genbetadev/Genbeta-Dev-Engine/issues/59#issuecomment-28167414 .

Mario Albornoz.

rickyah commented 10 years ago

@ficion cambios sin testear en develop como que no ¿eh? :P

angelnavarro commented 10 years ago

Yo, al igual que otros, soy totalmente nuevo tanto con C++ como con GitHub. Si los más experimentados en proyectos colaborativos creen que será beneficioso, voto a favor de usar dos ramas de desarrollo. Entiendo que mientras esté bien documentado para los que no tengan experiencia, no debería haber problema.

DavidBM commented 10 years ago

Me gusta la idea de una rama de desarollo y otra estable. Por mi usemos el método git-flow.

Además, todo lo que sea hacer buenas costumbres (aunque sean un poco exageradas con un proyecto como este) viene bien.

ficion commented 10 years ago

@rickyah No me refiero a que cualquiera suba lo que ni ha probado (vaya, que al menos funcione cuando se haga commit), me refiero a que por lo general no hay testeo más elaborado hasta después (¿funciona en otro SO? ¿qué pasa se se cambia esta opción?).

rickyah commented 10 years ago

@ficion Como digo depende. En ciertos lugares subir algo sin probar a develop no se permite, si se cuelan errores es por que se han pasado por alto, pero se prueba todo y se lanzan los tests antes de hacer el merge. Al menos es lo que se intenta donde yo estoy.

adrigm commented 10 years ago

Yo lo que digo es que ahora que estamos implementando la funcionalidades básicas no le veo sentido a tener varias ramas ya que todo lo que está de por sí ahora mismo es develop.

Mi propuesta es cerrar la Milestone 0.1 en Master y a partir de ahí las nuevas características que se quieran implementar van a develop.

¿Cómo lo véis?

RdlP commented 10 years ago

Yo creo que esto que comenta @adrigm es lo correcto. Yo opino que deberíamos esperar a acabar la 0.1 y tener una master y a partir de la 0.1 hacer la división de ramas.

danigomez commented 10 years ago

Para mi está bien, yo por ejemplo no termino de manejar del todo bien git, y tener que ir cambiando de branch a partir de ahora seria un dolor de cabeza...

rickyah commented 10 years ago

Ok, por mi vale. Sin embargo no es tanto dolor de cabeza cambiar de ramas, de hecho es como se trabaja en git, así que yo recomendaría acostumbrarse.

Digo que no es dolor de cabeza por que es trabajar con DOS ramas: develop y otra rama con la feature. Y en realidad ni eso, ya que trabajas en la feature, develop sólo la usas a la hora de hacer el Pull Request (y esto lo puedes hacer desde Github sin problemas)

Siempre podemos hacer un webcast o por irc algo así para la gente que no sepa manejar git :)

ficion commented 10 years ago

@rickyah La idea del IRC me gusta.

e-osuna-g commented 10 years ago

Si un IRC =D a mi también me gusta la idea.

2013/11/11 Ficion notifications@github.com

@rickyah https://github.com/rickyah La idea del IRC me gusta.

— Reply to this email directly or view it on GitHubhttps://github.com/genbetadev/Genbeta-Dev-Engine/issues/59#issuecomment-28238755 .

adrigm commented 10 years ago

El problema del IRC es que se tiende a planificar y tomar muchas decisiones entre los 2-3 que están conectados en ese momento. La esencia del proyecto es el aprendizaje y que cualquiera pueda llegar y revisar la elaboración de este proyecto y aprender como se hicieron las cosas. Si sacamos eso de aquí no quedará constancia y se perderán todas las discusiones que estamos dejando registradas.

Además de que si alguien se incorpora nuevo al proyecto y lee, por ejemplo, el issue del log sabe enseguida como ha evolucionado y que estamos haciendo ahora. Si empezamos a desviar las decisiones a otros canales eso se perdería.

rickyah commented 10 years ago

Me refería a un IRC para aprender lo básico de git

adrigm commented 10 years ago

En ese caso, siempre se pueden formar charlas improvisadas, pero cada vez que llegue un novato habrá que ponerlo al día. ¿No es mejor algunos artículos en la wiki?

rickyah commented 10 years ago

Se ha puesto un link a un libro de git y a git-flow

adrigm commented 10 years ago

¿Entonces cual es el objetivo del IRC?

De hecho lo puse yo el enlace al libro.

rickyah commented 10 years ago

Que la gente nueva aprenda a gestionar un par de ramas en git. No es algo muy complicado pero si hay gente que tiene problemas, pues se les puede echar un cable.

rickyah commented 10 years ago

Perdona que fuera tan escueto/borde en las contestaciones, es que estaba metido en faena con el Xcode que con los parámetros por defecto pone los ejecutables donde le sale de los webos ¡literalmente! Estaba poniéndome de mala sangre de la desesperación :( De hecho ni me fijé que eras tú @adrigm por que contesté directamente haciendo un reply al mail.

A ver que me explico. La cosa es que si hay gente que está colaborando en el proyecto y cambiamos a usar master/develop/feature en el repo, simplemente un tutorial para que sepan cómo va. Dije IRC por decir algo, pero vale un tut en la wiki o algo así.

Lo mejor, obviamente es aprender con el libro de git-pro que no hay excusa, está en castellano, pero era simplemente por si alguien necesita un cable, pero posiblemente sea mejor idea preguntar por aquí para que quede escrito y podamos referenciarlo a gente que entre nueva.

adrigm commented 10 years ago

Tranquilo! antes estuve mirando lo de Xcode yo también, lo máximo que conseguí fue que me creara una carpeta Debug dentro de bin con el contenido dentro, así que te deseo suerte xD

rickyah commented 10 years ago

Lo logreee!!! xD Voy a preparar todo y hacer otro PR con el Xcode bien configurado :S

angelnavarro commented 10 years ago

Aporto mi opinión de novato XD. Creo que es más conveniente dejarlo por escrito. Aprovecho para plantear una duda... He empezado a leer el libro de Git (voy por el tema 2) y tengo una duda que no sé si viene ahí o no, y si me la resolvierais ya me ayudaría a ponerme al día. El caso es, ¿vosotros trabajais directamente con el proyecto de Genbeta o cada uno tiene un fork propio del proyecto y luego une sus cambios al principal? espero que sea un lugar más o menos adecuado para plantearlo

Muchas gracias y un saludo

adrigm commented 10 years ago

Cada uno trabaja en su fork y cuando tiene algo listo solicita Pull Request

angelnavarro commented 10 years ago

Ammm ok. Entonces entiendo que el Pull Request no es desde tu local al servidor, sino desde tu fork al Genbeta (principal). Perfecto, muchas gracias @adrigm

adrigm commented 10 years ago

A partir de ahora ya no habrá mas commits directos al repositorio, hasta ahora solo los hacía yo, pero ya ni eso. Ahora yo tendré los cambios en mi repositorio y cuando algo esté listo también haré pull request. Así queda todo mejor organizado.