Buen artículo , se podría para los que somos de consola por favor aún me cuesta entender como funcionan los procesos y la forma en la que lo explicas con manzanitas es lo que necesito. Gracias
]]>Hola Pedro:
Tendría que buscar un rato para actualizar este tutorial a línea de comandos. Siendo sincero, en este momento estoy un poco liado y no voy a poder hacerlo a corto plazo. Tomo nota de vuestra petición.
Muchas gracias por tu tiempo.
]]>¡Me uno a esta pregunta!
¿cómo podemos hacer esta parte del tutorial desde la consola, a base de órdenes de terminal?
¡Muchas gracias!
]]>¡¡Gracias!! Me alegro de que te haya resultado útil.
]]>Gracias por tu rapidez en responder Alfonso.
Te comento, todos los proyectos son Java.
Nuestra idea pasa por tener un repositorio por componente / proyecto y luego crear las dependencias mediante Maven. Mi duda es ¿en el caso de que usemos esta opción deberíamos tener 3 proyectos o 2? 3 para tener cada componente y otro con el proyecto padre o 2 para tener uno por cada componente e indicar las dependencias en el fichero pom correspondiente.
Hemos realizado lo siguiente; hemos clonado un proyecto y mediante git subtree hemos añadido una dependencia ubicada en otro repositorio distinto, consiguiendo con esto el merge del código de la dependencia en el proyecto padre (por ejemplo gestion-wm)
Teniendo el remote del módulo apuntando a su repositorio particular podría publicar mis commits en este repositorio, aunque tengo que ver como diferenciar que el commit va al repositorio de gestion-wm o al de gestion-model.
Lo que no me acaba de quedar claro es como hacer que en el tag 1.1.3 por ejemplo de gestion-wm se especifique que la versión que se usa de gestion-modelo es la 1.8.1. por cambios que se han publicado en el desarrollo de la última «feature»
Nuevamente muchas gracias por tu ayuda.
Javier Montesinos
]]>Hola Javier:
La primera pregunta que te haría es ¿en qué lenguaje de programación están esos proyectos? El motivo es el siguiente: el problema que necesitas resolver es un problema de gestión de dependencias y para ese problema existen múltiples soluciones que hay que analizar. En los cursos que doy, esta es una pregunta recurrente y en cada caso la discusión y conclusiones a las que llegamos son diferentes. Te voy a dar cuál es el criterio que yo sigo y a poner luego un ejemplo comentamos hace un par de meses en uno de los cursos.
Mi criterio es que si tu lenguaje de programación o framework tiene un gestor de dependencias, úsalo. Yo programo principalmente en PHP y Ruby/Rails (y objectiveC cuando puedo y me dejan) así que lo que haría sería crear dos repositorios git independientes (uno para gestin-wm y otro para gestion-modelo), crearía un «paquete», «gema» o como quieras llamarlo y los incluiría en el proyecto «gestión interna» utilizando este gestor de dependencias:
Siguiendo con mi criterio: si tu lenguaje, infraestructura o plataforma de desarrollo no soporta gestores de dependencias o no puedes utilizarlos (cosa que ya me ha pasado), entonces hay dos opciones: git submodules y/o git subtree merging. En cualquier de los dos casos, tendrías tres repositorios git independientes: uno para el proyecto principal y uno para cada «modulo» de tu proyecto. Tanto submodules como subtree te permiten, así contado en breve, incluir unos repositorios git dentro de otros.
Una de las principales diferencias con subversion a la hora de organizar repositorios es que la tendencia en git es tener muchos repositorios pequeños en lugar de uno sólo del que cuelgan todos tus proyectos y dependencias.
También puedes hacerlo a tu manera. Te pongo un ejemplo que estuvimos comentando en uno de los cursos, dentro de un equipo que trabajaban con Java:
Este flujo tiene sus ventanas y sus inconvenientes. En su caso he de decir que era altamente efectivo, aunque quizás académicamente no es la forma más limpia de hacerlo. Dado que los ficheros .jar que generaban apenas pesaban unos cientos de Kb y no cambiaban muy a menudo, con un flujo muy sencillo y sin complicarse la vida con los submodules de git, tenían el problema resuelto en poco tiempo y con muy poco esfuerzo, que es lo importa al fin y al cabo en nuestro día a día.
Espero haberte ayudado y si tienes cualquier otra pregunta, aquí me tienes.
Un saludo.
P.D. Por cierto, he estado viendo tu post sobre git-flow, muchas gracias tanto por los comentarios como por los enlaces y referencias.
]]>Muchas gracias por tus artículos han sido de gran ayuda para iniciarme en Git. Quería comentarte una cosa a ver si me puedes echar un cable, no sé si es el lugar adecuado.
Estamos migrando de Subversión a Git tacha !!! Para ponerte en situación tenemos en un repositorio de subversion diferentes proyectos de modo que algunos de ellos son dependencias para otros por ejemplo tengo un proyecto «gestion interna» que puede tener dos subproyectos o módulos «gestion-wm» y «gestion-modelo». Este segundo proyecto gestion-modelo es una dependencia para otro proyecto.
Estoy planteando la migración de tal forma que:
gestion-wm vaya a un repositorio con su rama master, develop… para aplicar git-flow
gestion-modelo irá a otro repositorio con su rama master,develop…
Como puedo incluir el código de getion-modelo en gestion-wm o culaquier otro proyecto que lo utilice como dependencia? He estado viendo las opciones de submodules y subtree, pero no acaban de quedarme claras. Por lo que he leído en todos sitios recomienda el uso de Subtree.
Si por ejemplo saco una nueva versión de gestion-wm la 1.1.12 y esa versión implica cambios en gestion-modelo como puedo hacer para que en el tag de la 1.1.12 se haga referencia a la versión concreta de gestion-modelo que se debe usar y de modo que esta sea compartida por todos los proyectos que puedan usar gestion-modelo.
Espero haberme explicado.
Una vez más, muchísimas gracias por la ayuda que tu blog me ha prestado.
Javier Montesinos.
]]>Hasta ahora lo que he podido hacer es:
Paso 1:
git remote add aprendegit [email protected]:aprendegit/fork.git
Paso 2:
git pull aprendegit master
Paso 3:
git push aprendegit master
Esta correcto trabajar de esta forma.??
Que diferencias existe entre pull y fecth que veo en tu explicación.
Me viene de perlas para hacer mi primera aportación a un plugin de wordpress y practicar lo que vimos en el curso que impartiste.
A practicar mi inglés. 😉
]]>¡¡Genial!! Escribiré la entrada de todas formas, será más fácil de encontrar la información que en los comentarios.
¡Y gracias por tus palabras!
Alfonso
]]>Enhorabuena de nuevo por el blog… no se que haríamos sin blogueros como tú xD
]]>Sí, te has explicado. Lo que quieres hacer es posible hacerlo, tienes que jugar con la opción fetch de la definición del remote deltro del .gitconfig Te ha quedado claro ¿verdad? 🙂 Escribo una entrada en el blog al respecto, es una muy buena pregunta.
Te paso una copia de un trozo de la configuración de uno de mis repositorios en la que sólo me bajo las ramas fast/*, para que veas por dónde van los tiros:
[remote "origin"]
url = ssh://gitolite/interno/proyecto1/web.git
fetch = +refs/heads/fast/*:refs/remotes/origin/fast/*
Si sólo quieres trabajar con una rama, digamos que se llama «laquemeinteresa», tu fichero .git/config debería incluir una línea parecida a esta:
[remote "origin"]
url = ssh://gitolite/clientes/grito/web.git
fetch = +refs/heads/laquemeinteresa:refs/remotes/origin/laquemeinteresa
de forma que al hacer git-fetch, sólo se traiga esa rama.
Mira la página de manual de git-fetch, en particular la sección en la que hablan de lo que es un <refspec>. O dame unos días y lo cuento por aquí un poco más legible ;-). Para evitar historias, si vas a probar, haz una copia de seguridad del repositorio completo antes de trastear.
Alfonso
]]>Lo leo y no me entero ni yo xD Por si fuera necesario, tengo:
Origin: mi fork de upstream en github
Upstram: el repositorio original, al que tengo acceso de solo lectura
workingcopy: mi copia local.
Procedimiento de trabajo:
Varios desarrolladores tienen workingcopy de Origin. Modifican y commitean como si fuera un repositorio normal
Yo primero hago pull de Origin. Hago mis modificaciones. Hago fetch (de upstream). Elimino ramas innecesarias. Hago merge. Resuelvo conflictos. Hago push para tener Origin con las modificaciones propias y las de upstream.
Gracias por responder, no has tardado tanto 🙂
Las borro con click derecho -> delete branch en sourcetree. Lo que me interesa realmente es que no me las baje de nuevo al hacer fetch. probé a poner lo que te comenté en la url del remote, pero igual cometí un error de sintaxis, veo que tu dejas un espacio antes de los «:»
De todas formas creo que me expliqué de mal a fatal. Lo que me interesa es bajarme a local solo una rama al hacer el fetch, de forma que al hacer el push me pueda despreocupar de las otras ramas, que no me interesan.
Es decir, en mi fork ya eliminé las ramas al crear el fork, directamente desde la página de github, ahora lo que me interesa es que no cometa el error de hacer un merge y que me mergee (que verbo tan horrible) todas las ramas (sobre todo porque en el repositorio original ya van mergeando entre sus ramas cuando lo creen oportuno, así que lo que interesa de esas ramas me viene dado en la rama de mi interés)
Espero haberme explicado mejor xD
]]>