TODOPIC
Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: Picuino en 04 de Febrero de 2017, 09:20:43
-
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) (https://github.com/taweili/ardublock) en mi cuenta.
2. En el proyecto original, hay un issue 159 (https://github.com/taweili/ardublock/issues/159) que informa de un problema de compatibilidad con Arduino.
3. Hay una petición pull 160 (https://github.com/taweili/ardublock/pull/160) desde otro fork de facchinm (https://github.com/facchinm/ardublock/commit/0e89af08f027e49e2acc7564d7169f71947ba9cb) 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 (https://github.com/taweili/ardublock/issues/159).
Como estoy comenzando con GitHub, otro problema que encuentro es diferenciar "issue" y "commit"
Un saludo.
-
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.
-
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.
-
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).
-
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.
-
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!
-
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
-
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
-
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 :z) . 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.
-
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.
-
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.
-
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.
-
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
-
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:
- Tienes que ingresar para ver archivos adjuntos -
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:
- Tienes que ingresar para ver archivos adjuntos -
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!
-
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.
- Tienes que ingresar para ver archivos adjuntos -
Saludos!
-
Muchas gracias elgarbe. La explicación está genial.
Desde luego me queda claro que trabajar con Git es bastante complejo.
Eso no tiene por que ser malo, cuanto más complejo es más potencia tiene y a fin de cuentas manejar proyectos no es sencillo.
Pero ahora que empiezo estoy bastante saturado con tanta nomenclatura y manejo del workflow.
Las imágenes del sourcetree me vienen genial para hacerme una idea gráfica del workflow.
De todas formas voy a intentar trabajar en línea de órdenes. Soy de la vieja escuela, me siento más cómodo escribiendo texto.
Quizá es más lento y difícil, pero cada vez que consigo algo con un archivo por lotes, lo guardo y me puede servir más tarde para repetir lo mismo o repasar lo aprendido.
Un saludo.
-
No hay porque!
Sourcetree trae una terminal de comandos, yo creo que la parte grafica es fundamental. Yo intente con comandos y si bien es rapido, cuesta mucho al principio entender muchas cosas. Por ejemplo, el hecho de que en mi disco rigido ahora tengo todo el codigo de facchinm, mas el del proyecto original y que cuando cambio de branch para estudiar uno u otro se me cambian los archivos en el disco. Tambien es dificil de ver cuantos commits estoy por detras o por delante de otra persona que esta trabajando en el mismo proyecto. Realmente no creo que pueda trabajar sin la parte gráfica.
Tambien estoy de acuerdo que los comandos siempre es mejor ingresarlos a mano, uno aprende más, fija mejor las ideas y puede automatizar tareas.
yo hace rato que quiero comenzar con u nrepositoro propio de algunos proyectos de los cuales me gustaria me ayuden otras personas. Si me animo voy a comenzar con uno en breve.
Saludos!
-
Tienes toda la razón con la parte gráfica.
Tengo ciertos reparos con el software no libre. ¿Hay alguna buena alternativa a sourcetree en opensource?
Por ahora ya he conseguido traer el commit a mi disco local:
1º Hacer una copia local:
git clone https://github.com/usuario/ardublock picuino-ardublock
2º Cambiar al directorio de la copia local
cd picuino-ardublock
3º Si la copia local ya estaba hecha, tengo que sincronizarla con el repositorio en GitHub:
git pull
4º Crear un nuevo branch para realizar modificaciones y cambiar al nuevo branch:
git checkout -b fixArduino1612
5º Listado de branches del proyecto:
git branch -a
6º Traer a mi disco local el proyecto donde está el commit que me interesa:
git fetch https://github.com/facchinm/ardublock
7º Copiar en mi branch el commit que me interesa (antes tengo que buscar su número de ID o sha):
git cherry-pick 0e89af0
8º Listado de commits:
git log --oneline
9º Si quiero volver a cambiar al branch master:
git checkout master
-
Por último subo al repositorio los cambios realizados en el branch local:
git push --set-upstream origin fixArduino1612
-
Tienes toda la razón con la parte gráfica.
Tengo ciertos reparos con el software no libre. ¿Hay alguna buena alternativa a sourcetree en opensource?
Pero el sourcetree no es de pago. Es gratis, no es codigo abierto, pero lo puedes usar libremente.
Me alegro que hayas podido hacer los comando. Hay 1 o 2 que no son los tipicos, pero igual seguro funcionan.
sds
-
He encontrado GitExtensions (https://sourceforge.net/projects/gitextensions/) para Windows. OpenSource y por lo visto bastante potente. Voy a probarlo.
-
Ahora tengo un problema que no sé resolver.
Cuando borro archivos de código no aparecen como cambiados.
Cuando cambio a otro commit anterior con el modo --hard, tampoco cambian los archivos.
Cuando cambio de branch, tampoco cambian los archivos locales.
He reinstalado Git y Git Extensions y todo sigue igual.
No sé que hacer.
-
no entiendo, cuando borras un archivo completo o cuando borras lineas de código dentro de un archivo?
-
En los dos casos. En todos los archivos. Si hago un listado aparecen todos los archivos, git ls, pero no se actualizan.
Me ha sucedido despues de un stash. A pesar de quitarlo, git se ha quedado congelado.
He bajado el repositorio de github y le pasa lo mismo.
Despues de probar de todo, de repente ha vuelto ha funcionar sin saber por qué.
Me gustaría saber que ha podido pasar para otra ocasión.
Jugaré con el stash en un proyecto nuevo a ver si consigo que se repita lo mismo.
Un saludo.