Manejar forks en GitHub

[Picuino]

Hola a todos.
Estoy desarrollando un proyecto en GitHub y encuentro algunos problemas para utilizarlo. Después de buscar en google me he quedado igual que estaba.

1. He creado un fork de un proyecto existente (Ardublock) en mi cuenta.
2. En el proyecto original, hay un issue 159 que informa de un problema de compatibilidad con Arduino.
3. Hay una petición pull 160 desde otro fork de facchinm que soluciona el problema, pero todavía no se ha llevado al master del proyecto original (y lleva así varios meses)

¿Cómo puedo llevar esta solución a mi proyecto master?
Un tal gregcorbett ya ha lo ha hecho y aparece comentado al final del issue 159.


Como estoy comenzando con GitHub, otro problema que encuentro es diferenciar "issue" y "commit"


Un saludo.

[KILLERJC]

Creo que esto responderia tu pregunta:

http://softwareengineering.stackexchange.com/questions/148003/pulling-in-changes-from-a-forked-repo-without-a-request-on-github

Respecto a esto:

otro problema que encuentro es diferenciar "issue" y "commit"

Lo que yo entiendo es:

Un issue es un problema, es como un reporte de bugs, una persona pide que se investigue xxx cosa. La persona encargada revisa si puede reproducirlo, si es real o si se debe al codigo, si es asi le asignara algun tipo de prioridad. Finalmente alguna persona resuelve, via fork o branch. Para luego ser revisado por otra persona y juntado "merge" con el codigo principal.

El commit es una nueva pedido de actualizacion (registrar los cambios) y es local. Es decir, podes cambiar algo y usar un commit registrando el cambio, cambiar otra cosa y registrar el nuevo cambio. Y recien alli hacer el pull o pedido del mismo para que se suba a github. Al principio confundi el commit utilizandolo como para designar una version, pero luego me di cuenta que para eso estan los tags.

Igual todavia no tengo demasiado claro el manejo del GIT (especialmente en el merge que hay bastante reglas), a pesar que lo empeze a usar porque me facilita el uso en varias computadoras. Pero no tengo un manejo avanzado ya que no lo uso cuando hay muchas personas con manos en el mismo repositorio, sino en algo propio.

----

Imagino que alguna otra persona que este involucrado desde hace un tiempo en programacion con un grupo de personas debera tener bien en claro todos estos conceptos y darte una mejor respuesta. Eso es todo lo que conozco hasta hoy en dia, por que realmente no necesite otra cosa aparte de esa. Lo maximo que hice fue haber creado un branch de algun proyecto que tenia funcionando para implementar el manejo del mismo de otra forma. Si resultaba en algo bueno, procedia a merge con el master. Sino resultaba eliminaba el branch.

Ahora lo que me esta interesando es el Unit Testing, el cual debo poner en practica.

[Picuino]

Muchas gracias KILLERJC

Entonces en un issue en el que informas de un problema ¿se puede dar en el mismo issue la solución? ¿o sólo es una conversación en la que se comenta el problema y que no tiene código asociado?

Lo que quiero es hacer un fork del proyecto original para modificarlo por mi cuenta, sin trabajo colaborativo. De manera que la gestión de mi fork será sencilla.
El problema es que mi fork evolucionará por otro lado y se diferenciará cada vez más del original, pero quiero seguir trayendo del proyecto original las actualizaciones que hagan en el core.

Yo solo voy a añadir nuevas funciones mías, cambiar el aspecto y eliminar algunas funciones para que sea más ligero, pero no voy a cambiar nada en el core (las funciones de base). El core seguirá siendo el mismo que en el proyecto original y quiero traerme todas las actualizaciones que se hagan en él desde el proyecto original de la manera más automática posible, sin tener que codificar yo a mano.

La gestión de software colaborativa siempre es difícil y Git da muchas opciones y es muy versatil con el coste de un aprendizaje complejo. Iré poco a poco.

Un saludo.

[Picuino]

En el enlace que me has dado un "padre" pregunta cómo traer una modificación que se ha hecho en un "hijo"

En mi caso, mi proyecto es un "hijo" que quiere traer una modificación hecha en otro "hijo" y que el "padre" no ha aceptado (merge) todavía.

En el enlace, por lo que he entendido, comentan como sincronizar todo el proyecto, pero yo quiero sincronizar solo un issue solucionado.
Ese issue solucionado se ha enviado como pull al proyecto padre, todavía no se ha aceptado, y quisiera traerlo a mi proyecto hijo (solo el issue solucionado y nada más).

[Picuino]

Este es el arbol con el proyecto original y algunos forks:

taweili/ardublock
   |-- facchinm/ardublock
   |-- TomKeddie/ardublock
   |-- Picuino/ardublock

Hay un commit en facchinm/ardublock que soluciona el problema de compatibilidad con Arduino:
   https://github.com/facchinm/ardublock/commit/0e89af08f027e49e2acc7564d7169f71947ba9cb

Por lo visto TomKeddie (otro hijo) ya ha traído este commit a su proyecto para solucionar el problema:
   commit:  https://github.com/TomKeddie/ardublock/commit/0e89af08f027e49e2acc7564d7169f71947ba9cb
   merge pull request:  https://github.com/TomKeddie/ardublock/commit/75735a39bd5a5b98b569a6ca24c24c22ae7a291e
   merged commit:  https://github.com/TomKeddie/ardublock/pull/2/commits/0e89af08f027e49e2acc7564d7169f71947ba9cb

Yo también lo podría traer a mi proyecto mediante un pull y posterior merge, pero no sé como hacerlo.

[elgarbe]

Picuino, lo que estas tratando de investigar es el workflow de git. Hay muchos workflow diferentes. En tu caso, en el que quieres tener en odo privado un proyecto que esta en la red puedes hacer varias cosas:

• Fork del proyecto: De este modo tienes en tu cuenta de github (internet) una copia del proyecto.
• Clonas ese Fork a tu directorio de trabajo local. Querrás tenes copia local para trabajar en tu PC en vez de en internet
• Luego empiezas a editar archivos y por cada cambio importante haces un commit a tu copia local. Es importante hacer muchos commits para luego poder ir hacia atras en algo que le erraste y para tener documentado todo lo que fuiste tocando y por que (en el mensaje del commit)
• Cuando ya tengas muchas cambios y lo quieras resguardar en tu cuenta de github hase un push y se subirán los cambio
• Muchas veces se recomienda hacer un branch para cambios importantes bajo prueba. Por ejemplo test_AlgoImportante. Si ese branch evoluciona de modo satisfactorio, luego haces un merge al tu rama o branch master

De este modo solo vos haces cambio y no estas pensando en compartirlos.

Si qiusiseras compartir los cambios con el proyecto original la cosa se pone un poco mas dificil. Seguramente estaras obligado a hacer branchs de testeo para luego solicitar Pulls Requests.

Busca un poco en sourcetree github workflow y seguro te sacaras muchas dudas. Igual te prevengo, git es muy completo/complejo. Dominarlo bien lleba mucho tiempo y la mejor forma de apreder es colaborar en proyectos. los masters que quieran tus cambios te van a explicar como trabajar.

Por otro lado, los issue son simplemente marcas de problemas, es como una lista e problemas/mejoras solicitados. Los commits no tienen nada que ver y lo que siempre resuleven los issues son Pulls Request que el master aprueba y hace el correspondiente Merge. Los pulls request pueden hacer referencia a un issue. Es muy raro que alguien haga commit directamente sobre la rama Master, generalmente todo se hace en branch de testeo y luego por medio de pulls request se "mergean" o no.

Saludos!

[elgarbe]

Este es el arbol con el proyecto original y algunos forks:

taweili/ardublock
   |-- facchinm/ardublock
   |-- TomKeddie/ardublock
   |-- Picuino/ardublock

Hay un commit en facchinm/ardublock que soluciona el problema de compatibilidad con Arduino:
   https://github.com/facchinm/ardublock/commit/0e89af08f027e49e2acc7564d7169f71947ba9cb

Por lo visto TomKeddie (otro hijo) ya ha traído este commit a su proyecto para solucionar el problema:
   commit:  https://github.com/TomKeddie/ardublock/commit/0e89af08f027e49e2acc7564d7169f71947ba9cb
   merge pull request:  https://github.com/TomKeddie/ardublock/commit/75735a39bd5a5b98b569a6ca24c24c22ae7a291e
   merged commit:  https://github.com/TomKeddie/ardublock/pull/2/commits/0e89af08f027e49e2acc7564d7169f71947ba9cb

Yo también lo podría traer a mi proyecto mediante un pull y posterior merge, pero no sé como hacerlo.

Lo que deberías hacer es agregar en tu copia local un nuevo remote, que apunte al que tiene los cambios hehos. Luego haces un fetch o un pull de ese remote para obtener el branch/commit o lo que haya hecho. Finalmente hacer un merge a tu copia local.
No estoy muy seguro en la practica, pero así debería ser. A la noche si me hago un rato pruebo

[Picuino]

Muchas gracias elgarbe.

El workflow lo voy teniendo claro. La mayor parte de lo que comentas lo conocía (estoy ahora con ello).
La forma que comentas de trabajar me viene muy bien y el comentario de los issue me aclara las cosas.

No tengo tan claro cómo relacionar un issue con un pull request, para que aparezca en la página que uno es la solución del otro.

¿Tú cómo trabajas en local? ¿Con git en línea de órdenes, con la aplicación de escritorio de GitHub (que no me gusta nada) o con otra aplicación?


Creo que aquí se explica mi duda sobre cómo traerme un commit de otro proyecto diferente al mío:
http://stackoverflow.com/questions/4581740/pull-in-changes-from-a-github-fork

[Picuino]

Lo que deberías hacer es agregar en tu copia local un nuevo remote, que apunte al que tiene los cambios hehos. Luego haces un fetch o un pull de ese remote para obtener el branch/commit o lo que haya hecho. Finalmente hacer un merge a tu copia local.
No estoy muy seguro en la practica, pero así debería ser. A la noche si me hago un rato pruebo

Me he quedado un poco a cuadros  . Voy a estudiar el manual de git para ver si entiendo todo lo que me has escrito.

¿Hay algún manual que no sea demasiado extenso ni demasiado corto, de unas 100 páginas?

Saludos.

[elgarbe]

El link de KILLER debería servir, coincide con lo que te comente.
Yo uuso sourcetree.
En este momento hice el fork de  taweili/ardublock a mi cuenta de github, luego entro a sourcetree y clono el fork a my disco rigido, de ese modo se crea lo que se llama working copy o copia local.
Lo que vou a hacer despues es agregar un remote de ese repositorio para poder tener el codigo de fachinm. Para ello voy a hacer un fetch. Cuando llegue ahi te sigo contando. Te recomiendo bajes e instales sourcetree asi podemos hacer lo mismo.

sds.

[Picuino]

Glosario de GitHub: https://help.github.com/articles/github-glossary/
Glosario de Git: https://www.kernel.org/pub/software/scm/git/docs/gitglossary.html

Voy a bajar sourcetree.

[Picuino]

Me pide contraseña y que me cree una cuenta con ellos 
Además trabaja con el ratón y quiero automatizar ciertas tareas con archivos batch.

Intentaré seguirte con Git en línea de comandos.

[Picuino]

Proyecto clonado en local:
git -clone https://github.com/USUARIO/ardublock

Mejor aún, voy a copiarlo en un directorio que especifique el propietario del proyecto:
git -clone https://github.com/USUARIO/ardublock   USUARIO-ardublock

[elgarbe]

Yo daría un paso a la vez. Primero source tree luego linea de comandos. Pero no pierdes nada con intentarlo.

Luego de agregar el remote y hacer el fetch de fecchinm veo esto en sourcetree:

ardublock-min.jpg
(133.05 kB, 1920x1080 - visto 439 veces)

Como vez hay 3 branchs (ramas) master. El que dice origin es la copia de master que tienes en github, el que dice solo master es tu copia local, luego esta fecchinm/master, el cual contiene el commit que te interesa.

Bien, lo que yo haría es crear un nuevo branch, para no tocar el master. Llamada test_FixArduino, este branch contendrá todos los cambios de tu master local ya que estara basada en ella. Luego de crear el branch debes hacer un checkout para pasar a la nueva branch. en sourcetree es automatico.

Luego, estando en el branch test_FixArduino hago click derecho en facchinm/master y elijo merge para tomar sus cambios y aplicarlos a mi nueva branch:

ardublock2.jpg
(122.12 kB, 1920x1080 - visto 408 veces)

Con esto ya tenes los cambios de facchin en tu copia local. si vas al explorador de windows veras los archivos atualizados. Si por algun motivo haces un checkout a master, volveras al codigo original del fork.
Yo te recomiendo trabajar asñi, con un branch separado, nunca hagas cambios directos en master si es que quieres trabajar en colaborativo. Al master solo lo toca el dueño del proyecto.

Cualquier duda estoy acá una hora màs.

Saludos!

[elgarbe]

Ahora lo que podrías hacer es un push de tu nuevo branch a tu cuenta github, con esto tendras la copia de seguridad en la red y es el paso previo a hacer un pull request al dueño del proyecto.

ardublock3-min.jpg
(123.65 kB, 1920x1080 - visto 392 veces)

Saludos!