Página personal de JStitch
Contents
1. F Row 1 6 Buscar Ex gt gt revisi n que contiene p Buscar Diferencia Versi n antigua Versi n nueva Lineas de contexto 3 F Ignora cal Autor Committer Padre 66015510bd5a3da9641a362be9b25 e553a301ca2 mis cambios al README y creando ne Rama 5ique a Precede a Cambios locales sin a adir al indice index eb9de29 eb67e6b 100644 aa 0 0 1 2 68 hola mundo Que nos muestra que s lo queda un cambio detectado por Git aquel que no hemos marcado para versionar a n master Que git C mo ve git versione estos archivo cambios E H git status git diff git commit Branches y Merges Para los provenientes de VCS centralizados como SVN muy probablemente el nombre Branch ya dibujo en su mente la idea de una pesadilla dantesca La realidad es que el manejo de branches en versionadores centralizados suele convertirse en una molestia m s que en una herramienta til Tan es as que muchos proyectos renuncian a su uso y se dedican nicamente a versionar sobre un rbol principal de c digo dejando de lado una de las ventajas esenciales que proporciona un versionador Pero la buena noticia es que en los versionadores distribuidos y en Git en particular el manejo de branches es dicho llanamente maravilloso Una manera de entender los branches en Git es adem s de olvidando lo aprendido en versionadores centralizados verlos como contextos en los que se trabaja una versi2. 5 removed binary file Added all T files First commit agrego cambio a README de prueba esperando generar conflicto en master master Y git pull git clone luego de un pull request mal Ta Conclusi n Con esto terminamos el recorrido por varias de las caracter sticas m s destacables de Git No est n todas las que son pero al menos las que est n pueden servir como un primer paso para comenzar a versionar utilizando esta grandiosa herramienta Git tiene muchas caracter sticas y comandos m s a los que hay que ir revisando para utilizarlo en toda su potencia Los comandos y opciones hasta aqu mencionados a n se pueden complementar con m s opciones Y como siempre para m s referencias consultar la documentaci n oficial p ginas del manual y google Lo nico que queda ya es estudiar como utilizar el servicio GitHub lo que haremos en la siguiente y ltima parte Mientras tanto como conclusi n a todo esto notar como el uso de un versionador se puede convertir en una de las herramientas m s tiles para administrar y manejar c digo fuente en diversos proyectos No es la nica herramienta importante mucho menos para proyectos de software libre pero s una de las m s fundamentales Claro en alg n momento tambi n habr que dedicarse a estudiar otras herramientas en cuanto a administraci n trackers de issues y bugs posiblemente admin
3. test remote gt invernalia test remote new tag vl 1 2 betal gt v1 1 2 betal Como se puede observar en ese servidor remoto alguien ya hizo un commit sobre el branch masterm_lang y agreg un nuevo branch test_remote y un nuevo tag v1 1 2 beta1 cambios que ya fueron bajados aunque el c digo a n no refleja ning n cambio todav a Como puede observarse Git hace un mapeo con los cambios hechos y los repositorios remotos As el branch masterm_lang del remoto invernalia se llama ahora invernalia masterm_lang Ahora podr a hacerse un git log para observar qu cambios ser n sincronizados y al final un git merge git log invernalia masterm lang oneline decorate graph 010040b tag v1 1 2 betal invernalia masterm lang agrego un archivo en el remote 23c4c4e origin masterm lang origin HEAD removed bianry file xi xi git log invernalia test remote oneline decorate graph laa265d invernalia test remote mas pruebas con archivo en branch de pruebas 010040b tag v1 1 2 betal invernalia masterm lang agrego un archivo en el remote 23c4c4e origin masterm lang origin HEAD removed bianry file Ur Es decir hay un commit en masterm_lang y dos commit en test_remote que por sus descripciones ya nos podemos hacer una idea de qu ser n git merge invernalia masterm lang Merge made by recursive new file from remote 1 1 files changed 1 insertions 0 deletions create mode 100644 new f
4. 18 11 11 07 13 15 38 11 07 15 15 36 11 07 15 15 35 11 07 15 15 34 11 07 13 15 32 11 03 14 23 14 11 03 14 23 01 11 03 14 22 49 11 03 14 22 47 Author Javier Novoa Javier Novoa Javier Novoa C Javier Novoa Javier Novoa Javier Movoa C Javier Novoa C Javier Novoa Javier Novoa Javier Movoa C Javier Novoa C Javier Novoa Javier Novoa Message 7 Merge remote tracking branch invernalia test_remo masterm lang Merge remote tracking branch inwernalia masterm_ mas pruebas con archivo en branch de pruebas west remote agrego un archivo en el remote w1 1 2 betal Merge luego de conflicto w1 1 2 agrego cambio a README esperando generar conflicto agrego cambio a README de prueba esperando genera testing agrego texto a new file corno prueba w1 1 2 beta mis cambios al README y creando new file removed bianry file Added files for brach masterm_lang Added all project files First commit Un vistazo al repositorio remoto luego del push se ven los cambios que originalmente se hab an hecho en el repositorio local git request pull Cuando no se tengan permisos para escribir en el repositorio remoto pero a n as se desee intentar colaborar Git proporciona un mecanismo para solicitar a quien mantenga el repositorio que le haga un pull o un fetch merge a nuestro repositorio local y as lograr enviar nuestros cambios Para lograr esto para empezar el r
5. Fd hera one aha fi d E Cdra ro at cambios E p aLarchivo Ja z pit add gl ko git statas 7 git commit alt dif Supongamos que ahora deseamos que el cambio en testing quede reflejado tambi n en masterm_lang Lo que debe hacerse es un merge una operaci n que la mayor a de las veces Git puede hacer por su propia cuenta git branch masterm lang testing git merge testing Updating 6601551 6870e92 Fast forward new file 2 1 files changed 2 insertions 0 deletions cat new file hola mundo Conflictos Pero qu pasar a si otro usuario hubiera hecho cambios a new_file sobre masterm_lang antes que nosotros hubi ramos hecho el commit Entonces Git generar a lo que se conoce como un conflicto que no es otra cosa sino la forma en que Git indica que no sabe como hacer el merge por s solo y necesita de la ayuda externa de los usuarios Los conflictos no ocurren siempre incluso aunque muchos usuarios hagan cambios al mismo archivo muchas veces B sicamente si los cambios se hacen sobre l neas diferentes del dicho archivo Git sabr hacer el merge sin problemas Es cuando se hacen cambios que inmiscuyen l neas iguales en el archivo cuando Git puede verse en problemas Ve moslo con un ejemplo recordando que a n hay un cambio sin versionar en README git checkout testing M README Switched to branch testing git add README git commit m agrego cambio a README de prueba esper
6. Mexico city 23 j anuary 2009 E lt lt lt lt lt lt lt HEAD hello README hola README gt gt gt gt gt gt gt testing Makefile the makefile to build masterm c the main source file masterm h the main header file cursors h the cursors interface curstextlib h the cursors inter languages h adds a basic transl FEEDBACK The current maintainer of Master at his email at jstitchagmail cc naranjamecanica00Ghotmail com e account Mexico city 23 j anuary 2009 hola README El resolviendo master E conflictos a git merge o ei J z Fama L jF janj y cae WENTE z WHatara 5 de A O k 5 2 Agrega FETH bliri aenmente pan F LAAS A TETEH oa TED F cinmiros i LA 1 ji pit add g t log Ar r git commit Y esa es la forma en que se trabaja con los branches en Git Con otros versionadores es posible lograr este mismo tipo de proceso y organizaci n pero requiere de administraci n extra por parte del usuario cosa a la que muchos proyectos no est n acostumbrados Obviamente para lograr sacarle provecho a los branches hay que tambi n organizarse un poco Este link puede ser til para quien busque alguna gu a pr ctica en ingl s git log Un sistema que maneja tan eficientemente tanta informaci n como Git no ser a nada til si no permitiera tambi n mostrar de manera ordenada dicha informaci n al usuario de forma que l pueda saber con exactitud alg n ped
7. c README utils h Si se observa el contenido de los archivos ocultos de este directorio se podr ver que efectivamente se tiene un repositorio Git en l S ls a BUGS curstextlib h HISTORY intl LICENSE masterm c README utils h cursors h git INSTALL languages h Makefile masterm h TODO origin git clone master Independientemente del m todo utilizado antes de comenzar a trabajar y si no se ha hecho a n es necesario indicarle a Git los datos que utilizar el sistema para saber qu usuario ser el responsable de los cambios hechos de otra manera no tendr a sentido el usar un VCS sin tener a qui n eeharte4acutpa darle gracias por los cambios hechos al c digo Esto se logra con los siguientes comandos git config global user name Tu nombre git config global user email tutdominio com Usando el repositorio local El funcionamiento b sico de Git consiste en trabajo local trabajo local y trabajo local modificando archivos generando branches haciendo merges con ellos agregando los archivos con cambios que se deseen versionar version ndolos y as sucesivamente Solamente cuando ya se tiene un conjunto de c digo y cambios hechos y probados se procede a mandarlos al repositorio origen desde el cu l se clon o a solicitar que se integren los cambios hechos al mismo en caso de no tener los permisos adecuados En resumen se utiliza git add para agregar los cambios a los archivos que se desea que Git tome
8. en cuenta para la siguiente versi n del c digo git status y git diff para observar los cambios puntuales que se realizar n para la siguiente versi n y git commit para almacenar dicha versi n en el historial del repositorio Este es el flujo principal que se sigue al trabajar con Git y hay que destacar que todo se hace de manera local sin interacci n con repositorios remotos recu rdese que se est trabajando sobre un repositorio local y que precisamente ste es el sentido de los VCS distribuidos git add Inicialmente ning n cambio a ning n archivo sobre el que trabajemos sea reci n creado o sea modificado aunque anteriormente ya hubieran sido versionados cambios al mismo es considerado por Git para versionar Es necesario hacer un git add para que Git sepa en particular qu archivos con cambios ser n versionados Esto proporciona un control muy fino del proceso de versionado En sistemas como SVN si un archivo es considerado para versionar lo es desde que es agregado al repositorio y hasta siempre Si deseamos modificar este archivo a n cuando esa modificaci n no tenga nada que ver con las modificaciones a otros archivos el proceso de commit se llevar de una sola vez a todos los archivos versionados En Git sin embargo tenemos la opci n de elegir puntualmente qu archivos con cambios se van a versionar As si hacemos una modificaci n que sea una correcci n de un bug en varios archivos y a la vez modificamos otros archivos
9. le indic a Git que los cambios se ir an a versionar en ese contexto los cambios pasan transparentes entre contextos echo hola README gt gt README git checkout masterm_ lang M README M new file Switched to branch masterm lang Your branch is ahead of origin masterm lang by 1 commit git status s o M README M new file Lo cual indica que los cambios que no se han marcado para versionar recu rdese que new file a n tiene cambios sin marcar pasan entre contextos de manera transparente Si ahora marcamos alg n cambio para versionar en uno de los contextos git add new file git status s M README M new file git checkout testing M README M new file Switched to branch testing git status s M README M new file Como se puede observar aqu tambi n los cambios marcados para versionar pasan transparentes entre contextos Git no puede saber si la marca agregada para versionar es para uno u otro contexto y s lo sabr informaci n m s concreta hasta hacer un commit git commit m agrego texto a new file como prueba testing 6870e92 agrego texto a new file como prueba 1 files changed 2 insertions 0 deletions Y ahora s los cambios hechos a new file quedan en el branch testing no en la rama principal cat new file hola mundo git checkout masterm lang M README Switched to branch masterm lang Your branch is ahead of origin masterm lang by 1 commit cat new file E
10. mismo remoto dependiendo las operaciones que se quieran hacer sobre ellas fetch lecturas y push escrituras a it remote Qu repositorios g remotos se tienen gt t Er Con git remote add se puede dar de alta otro repositorio remoto git remote add invernalia gitfinvernalia homelinux net masterm git git remote v invernalia gitltinvernalia homelinux net masterm git fetch invernalia gitltinvernalia homelinux net masterm git push origin git github com stitch masterm git fetch origin git github com jstitch masterm git push Y como se ve ya hay un nuevo repositorio remoto declarado en nuestro repositorio Git Ahora a usarlo Origin git remote add Agregar un repositorio remoto 2 git fetch merge pull Con Git hay dos opciones para obtener los ltimos commit de un repositorio remoto git pull Y git fetchlgit merge B sicamente el pull hace un fetch seguido de un merge pero si lo que se desea es tener mayor control sobre lo que se va a actualizar puntualmente y procediendo branch por branch el fetch merge siempre es mucho mejor opci n git fetch invernalia From invernalia homelinux net masterm remote Counting objects 5 done remote Compressing objects 100 2 2 done remote Total 3 delta 1 reused 0 delta 0 Unpacking objects 100 3 3 done From invernalia homelinux net masterm 23c4c4e 010040b masterm lang gt invernalia masterm lang new branch
11. n espec fica del c digo Digamos que bajamos el c digo fuente de un software que utilizamos mucho y detectamos un bug El modo Git de afrontarlo ser a luego de clonar el repositorio crear un branch y ah trabajar la correcci n del bug Si adem s resulta que tenemos una propuesta de mejora al software lo correcto desde el punto de vista del modo Git de trabajarlo ser a crear otro branch a partir del original o maestro y ah trabajar los cambios Finalmente cuando el bug est corregido se integran v a merge con el branch maestro Y cuando nuestros cambios est n hechos y probados tambi n se hace lo mismo desde aquel otro branch al maestro de nuevo As al final se tiene un c digo limpio probado bien versionado Todo gracias al uso de branches En resumen se crean branches con git branch se hace cambio de contextos con git checkout y se mezclan branches con git merge Otra caracter stica notable del manejo de branches de Git es que los branches creados no se crean aparte en subdirectorios dedicados a lo mismo como en SVN M s bien el directorio git contiene toda la informaci n en forma de snapshots o diferencias entre cada archivo y sus branches y as en un s lo directorio de trabajo del proyecto al cambiar de contexto todo el c digo del mismo directorio pasa a ese nuevo estado Se puede cambiar entre contextos libremente y sin p rdida de informaci n y sin el estorbo de un directorio dedicado a cada branch del proyec
12. new file pero la modificaci n hecha a este ltimo no aparecer Agregando editando archivos Cu 277 EA Modificado Agregado eliminaDo pendiente para versionar master C mo ve git archivo git status ge aLr Otra operaci n muy com n al trabajar con archivos versionados es la de observar y analizar los cambios hechos as como las diferencias entre la nueva versi n y la que se tiene en una versi n anterior Git utiliza diff para esto mismo como puede verse en el siguiente ejemplo echo hola mundo gt gt new file git diff diff git a new file b new file index e6 de29 7 5af59 100644 a new file b new file le 0 0 1 2 ee hola mundo new file Alles 0 0 1 2 en hola mundo Esta salida indica que Git detecta cambios que no han sido marcados para versionarse en el archivo new file una l nea nueva del ejemplo anterior y un mensaje del presente ejemplo Si se deseara ver las diferencias que Git detecta tomando en cuenta los cambios en los archivos que ya fueron marcados para versionar aunque a n no haya sido versionados se utiliza el par metro cachea git diff cached diff git a README b README index 0589 947a 082cf26 100644 a README b README afR 70 3 70 4 account Mexico city 23 january 2009 diff git a new file b new file new file mode 100644 index 0000000 e69de29 Como puede observarse aqu se muestran los
13. para corregir errores de tipograf a en la documentaci n Git nos permite versionar cada una de estas modificaciones por separado permitiendo identificar m s f cilmente qu archivos cambiaron como parte de qu modificaci n sin confundir con otros archivos relacionados a otras modificaciones Por ejemplo touch new file echo gt gt README git status s M README new file README m a 68 5 68 6 es account new file Mexico city 23 january 2009 README Y new file Hasta aqu se puede observar que tanto al agregar un nuevo archivo como al editar un archivo ya existente en el repositorio Git sabe que ambos archivos no ser an versionados en el pr ximo commit Lo que s sabe es que el archivo que ya hab a sido versionado ahora fue modificado pero no por ello lo versionar de nuevo y el archivo nuevo no sabe nada de l hasta ahora Ahora git add README new file git status s M README A new file Staged Changes Will Commit 7 README new file Y ahora s luego de git ada Git sabe que ambos archivos deben ser versionados uno por haber sido modificado y otro por haber sido a adido Si s lo uno de los archivos debe ser versionado entonces git add s lo recibir a ese archivo como argumento Luego se versionar a con git commit y el otro archivo a n quedar a pendiente de versionar git status Hasta ahora para demostrar git add se us tambi n git status
14. push nos permitir subir nuestros cambios al repositorio remoto De lo contrario es necesario hacer una operaci n llamada pull request que explicar m s adelante git push invernalia masterm lang Counting objects 22 done Delta compression using up to 2 threads Compressing objects 100 16 16 done Writing objects 100 18 18 1 78 KiB done Total 18 delta 10 reused 0 delta 0 To gitttinvernalia homelinux net masterm git 010040b c932ba4 masterm lang gt masterm lang Como se muestra se enviaron al repositorio remoto los cambios del branch masterm_lang Tambi n podr an enviarse los del branch testing que dicho sea de paso no existe en el repositorio remoto eso cr anmelo as hice las pruebas git push invernalia testing Total 0 delta 0 reused 0 delta 0 To gittinvernalia homelinux net masterm git new branch testing gt testing Tambi n enviamos los tags git push invernalia v1 1 2 Counting objects 1 done Writing objects 100 1 1 213 bytes done Total 1 delta 0 reused 0 delta 0 To gitttinvernalia homelinux net masterm git new tad v1 1 2 gt v1 1 2 git push invernalia vl1 1 2 beta Counting objects Writing objects Total 1 delta 0 1 done 100 1 1 194 bytes reused 0 delta 0 done To gitfinvernalia homelinux net masterm git new tag v1 1 2 beta gt v1 1 2 beta Date 11 07 15 18 47 11 07 15 18 44 11 07 15 18 29 11 07 15
15. 1 2802 0c Login Register Buscar en este sitio Buscar A ses Pagina personal de JStitch Inicio Versionando con Git y Github Parte 2 Enviado por JStitch el Mar 12 07 2011 10 42 o C mo Introducirse al Software Libre siendo Programador A a es la parte 2 de una serie de posts que estoy realizando para hablar tanto de versionadores en general y de Git y el servicio GitHub en particular como del hecho de que para participar en un proyecto de software de cualquier ndole pero en especial los de software libre un control eficiente pero a la vez sencillo de las versiones del c digo es important simo En la parte 1 introduzco los conceptos de versionadores esquematizo el proceso que en general se sigue para utilizar un sistema as hablo de la historia de los versionadores y termino diferenciando los versionadores centralizados de los distribuidos En esta parte hablar de Git un sistema de control de versiones distribuido bastante popular Si ya conoces sobre Git y te interesa pasar directamente a la parte de GitHub puedes ir a la parte 3 Git Este post se concentra en introducir el sistema de control de versiones version control system VCS Git Para explicar Git y sus conceptos como VCS utilizo la interfaz m s com n del sistema la l nea de comandos Por ello este post est plagado de comandos de la mano de los conceptos explicados Mi recomendaci n para entender Git es entender los conceptos con
16. E y creando new_file Como se puede observar el comando necesita de un mensaje descriptivo y de hecho Git lanza error si no se agrega mensaje Ahora git status s M new file Cambios locales sin a adir al ndice mis cambios al README y creando new file Javier Novoa Cal remotes origin removed bianry file Javier Novoa Added files for brach masterm_lang Javier Novoa Added all project files Javier Novoa First commit Javier Novoa SHA1LID MERA AEREA E gt Row z 6 Buscar Es gt gt revisi n que contiene y Buscar Diferencia Versi n antigua Versi n nueva Lineas de contexto 3 M Ignora car Autor Javier Novoa Cata o lt jstitch nrmweb _sysadmin none gt 2011 07 13 13 56 29 Committer Javier Novoa Cata o lt jstitch nrmweb sysadmin none gt 2011 07 13 13 56 2 Padre 23c4c4e0b77ac 9599ef2a751c61 86165bc56la removed bianry file Hija GOGOQOOCOOOOOOGOCOGCOOOOOOOOGOGOGOGOGOOG Cambios locales sin a adir al indi Rama masterm_lanqg 5ique a Precede a mis cambios al README y creando new file es 70 3 70 4 68 account Mexico city 23 January 2009 Cambios locales sin a adir al ndice mis cambios al README y creando new file Javier Novoa Ca i removed bianry file Javier Novoa C Added files for brach masterm_lang Javier Novoa Added all project files Javier Novoa First commit Javier Novoa SHA1ID MA
17. ado con BitKeeper un VCS de c digo cerrado que parad jicamente para muchos permit a administrar uno de los productos estelares en el ambiente del software libre Como es propio de l Torvalds no ced a a presiones basadas en preferencias y filosof as y continu con BitKeeper hasta que este proyecto lanz restricciones que no permit an un uso libre de los proyectos hosteados con ellos As pues como buen hacker Linus Torvalds comenz a escribir Git para llenar el hueco dejado por BitKeeper de un VCS distribuido elegante pero sobre todo eficiente para usar con Linux Si toda esta an cdota es o no una lecci n sobre filosof a del uso de software libre quede a criterio del lector Desde su lanzamiento el 6 de abril del 2005 Git se ha convertido en uno de los principales VCS distribuidos sobre todo pero no exclusivamente en el mundo del software libre Algunos de los proyectos que a d a de hoy utilizan Git como VCS son el kernel de Linux el proyecto Android el CMS Drupal el entorno de escritorio Gnome el lenguaje de programaci n Perl el manejador de ventanas Openbox Wine los servicios de compatibilidad Linux Windows las coreutils del proyecto GNU X Org el servidor gr fico para entornos Unix Qt el framework de aplicaciones gr ficas Samba la implementaci n libre del protocolo SMB para compartir archivos con sistemas Windows y un largo etc tera El modo Git Muy al contrario de como se maneja un VCS tradicio
18. ando generar conflicto en master testing 6d32c82 agrego cambio a README de prueba esperando generar conflicto en master 1 files changed 1 insertions 0 deletions Hasta aqu versionamos el cambio al branch testing git checkout masterm lang Switched to branch masterm lang Your branch is ahead of oriqin masterm lang by 2 commits echo hello README gt gt README git add README git commit m agrego cambio a README esperando generar conflicto cuando haga merge masterm lang aa7cca6 agrego cambio a README esperando generar conflicto cuando haga merge 1 files changed 1 insertions 0 deletions Ahora regresamos a masterm_lang y ah hicimos un cambio diferente sobre el mismo archivo en la misma l nea la ltima que el cambio que se version en testing Todo eso antes del merge Y ahora a ver que pasa git merge testing Auto merging README CONFLICT content Merge conflict in README Automatic merge failed fix conflicts and then commit the result git status s UU README tail README Mexico city 23 january 2009 lt lt lt lt lt lt lt HEAD hello READM hola README gt gt gt gt gt gt gt testing Qu sucedi Pues que Git no supo qu hacer y gener un conflicto al hacer el merge Este conflicto queda marcado para Git seg n el resultado de git status s y tambi n dentro del mismo archivo README como puede verse por los marcadores que se agregaron autom t
19. azo que le sea realmente til Para eso existe git log Este comando tiene en realidad muchos usos y muchas formas diferentes de generar y reportar la informaci n con que cuenta Git por lo que veremos solamente algunos ejemplos que podr an ser tiles git log commit 8ca28c3c01257ec7081l 6dee2ad9a4f9338395ab04 Merge 5bd2d17e 2f77f01 Author Javier Novoa C Dates Fri dul 15 10 38 12 2011 0500 Merge luego de conflicto commit 5d2d17e1773c417c89692db8e4eb7af46c442e13 Author Javier Novoa C Date Fri Jul 15 10 36 07 2011 0500 agrego cambio a README esperando generar conflicto cuando haga merge commit 2f77f0110cc5138db58050ced9247beb51b8532d Author Javier Novoa C Date Fri Jul 15 10 35 37 2011 0500 agrego cambio a README de prueba esperando generar conflicto en master commit 97bc9fbc9aa2e030c7981edafc9565f5a122f555 Author Javier Novoa C Date Fri Jul 15 10 34 44 2011 0500 agrego texto a new_file como prueba commit 4882d44687aa668fc4115f596552e431e5a6e9d1 Author Javier Novoa C Date Fri Jul 15 10 32 33 2011 0500 mis cambios al README y creando new_file commit 23c4c4e0b77ac69599 ef2a751c61786165bc561a Author Javier Novoa C Date Mon Mar 14 17 14 36 2011 0600 removed bianry file Esta es la salida por default de git 1og Muestra en bloques cada uno de los commits que se han hecho dentro del branch actual si estuvi ramos en otro branch y no se hubieran hecho los merge correspondientes podr a verse ot
20. cambios en el archivo README que ya hab an sido marcados para versionar anteriormente una l nea nueva del primer ejemplo Tambi n se muestra el nico cambio hecho a new file que ya hab a sido marcado para versionar la creaci n del archivo nada m s Por ltimo si lo que se desea es ver todos los cambios tanto de lo marcado para verionar como lo que no se le pasa a git diff como par metro la versi n contra la cual se quiere comparar el c digo actual El nombre HEAD se refiere a justamente la ltima versi n que tiene almacenada el repositorio git diff HEAD diff git a README b README index 0589 47a 082cf26 100644 a README b README af 70 3 70 4 account Mexico city 23 january 2009 diff git a new file b new file new file mode 100644 index 0000000 77 5af59 dev null b new file CQ 0 0 1 2 QQ hola mundo Que como puede observarse incluye los cambios tanto a README previamente marcados para versionar como los de new file algunos ya marcados y otros a n no marcados para versionar git commit Finalmente una vez hechos los cambios deseados a adidos nuevos archivos eliminados otros y a adidos dichos cambios espec ficos para ser versionados por Git ignorando por ahora los otros cambios que no deseamos versionar todav a se realiza el commit al repositorio recu rdese es local no hay necesidad de conexi n a la red todav a git commit m mis cambios al READM
21. eline decorate graph x 8ca28c3 HEAD tag v1 1 2 masterm lang Merge luego de conflicto IN 2 77f01 testing agrego cambio a README de prueba esperando generar conflicto en master 5bd2d17e agrego cambio a README esperando generar conflicto cuando haga merge 97bc9fb agrego texto a new file como prueba 4882444 mis cambios al README y creando new file 23c4c4e origin masterm lang origin HEAD removed bianry file Como se puede observar al usar el par metro decorate de git log que muestra m s informaci n sobre los branches tambi n se muestra ahora el tag que acabamos de generar para el HEAD del repositorio Obviamente tambi n se puede dar tag a alguna versi n diferente al HEAD para lo cual al comando git tag simplemente se le agregar a el identificador del commit al que deseemos ponerle el tag git tag a vl1 1 2 beta 97bc9fb git log oneline decorate graph x 8ca28c3 HEAD tag v1 1 2 masterm lang Merge luego de conflicto IN 2 77f01 testing agrego cambio a README de prueba esperando generar conflicto en master 5d2d17e agrego cambio a README esperando generar conflicto cuando haga merge 7 97bc9fb tag v1 1 2 beta agrego texto a new file como prueba 4882444 mis cambios al README y creando new file 23c4c4e origin masterm lang origin HEAD removed bianry file Para pasar el c digo de un tag a otro se puede usar el mismo comando git checkout pero en lugar de usar e
22. epositorio local debe estar configurado para poder proporcionar c digo a manera de un servidor configuraci n que queda fuera del espectro de este art culo git checkout masterm lang Switched to branch masterm lang Your branch is ahead of oriqin masterm lang by 9 commits echo nuevo cambio gt gt README y git add README git commit m otro cambio para probar pull request masterm lang 36260b0 otro cambio para probar pull request 1 files changed 1 insertions O deletions git tag vl1l 1 3 beta git request pull v1 1 3 beta gitfinvernalia homelinux net masterm git The following changes since commit 36260b08b8c3e0 baalb4d882d82cc8620fdb016 otro cambio para probar pull request 2011 07 15 14 26 07 0500 are available in the git repository at git invernalia homelinux net masterm git masterm_lang Para m s informaci n se puede consultar la p gina de manual de git request pull 1 otro cambio para probar pull request invernalia Merge remote tracking branch invernalia test_remote into masterm_lang mas pruebas con archivo en branch de pruebas Merge remote tracking branch invernalia masterm_lang into masterm_lang agrego un archivo en el remote e luego de conflicto Ss invernalla o cambio a README esperando generar conflicto cuando haga merge agrego texto a new_file como prueba mis cambios al README y creando new file in removed bianry file Added files for brach masterm lang
23. icamente al archivo en los lugares en donde ocurri el conflicto Y para resolver el conflicto se necesita la intervenci n humana Normalmente aqu es donde los desarrolladores responsables de los cambios que ocasionaron el conflicto se baten en euete ponen de acuerdo para decidir c mo resolver el conflicto Al final uno de los desarrolladores deber editar el archivo con conflicto dejar el cambio adecuado y retirar las marcas de conflicto lt lt lt lt y gt gt gt gt que coloc Git Esto lo puede hacer editando manualmente el archivo o con alguna herramienta de resoluci n de conflictos invocando git mergetoo l README LOCAL 6 ME REMOTE 6951 ADME LOCAL 6951 Ka T UDU g pend g O dO d RE B BUGS bugs reported and found tc Makefile the makefile to build EA cursors h the cursors interfacefe curstextlib h the cursors inter ADME REMOTE 6951 M UDU g pend d BUGS bugs reported and found tc 5 masterm c the main source file masterm h the main header file cursors h the cursors interface curstextlib h the cursors inter languages h adds a basic transl FEEDBACK The current maintainer of Master at his email at jstitchfgmail cc naranjamecanica00Gahotma1l com account Mexico city 23 j anuary 2009 hello README gt languages h adds a basic transl FEEDBACK The current maintainer of Master at his email at jstitchagmail cc naranjamecanica00Ghotmail com account
24. icto en master 5d2d17e agrego cambio a README esperando generar conflicto cuando haga merge 7 97bc9fb agrego texto a new file como prueba 4882d44 mis cambios al README y creando new file 23c4c4e removed bianry file Con el par metro graph se puede ver incluso de manera visual c mo han evolucionado los branches y los posibles merge hechos entre ellos Una opci n util sima Historial de versiones ye 1 git log git tag Para terminar con este asunto de los branches vamos a mencionar los tags Casi cualquier versionador permite manejar este concepto unos m s f cilmente que otros La idea detr s de un tag es tener una especie de fotograf a fija del proyecto en cierto momento De esa forma cuando se quiera tener el c digo del proyecto justo como se tuvo en el momento de tomar la fotograf a simplemente uno va al tag y lo recupera Esto es sumamente til cuando por ejemplo se tiene el proyecto en un estado listo para liberar a un entorno de producci n A n se planean mejoras se planea mantenimiento pero en ese estado justamente se decide tener la digamos versi n 1 1 2 del software Entonces se genera un tag del momento del proyecto deseado se le etiqueta como versi n 1 1 2 y listo Git tiene la informaci n que nosotros podemos usar cuando deseemos por ejemplo regresamos el c digo al estado de ese tag y luego empaquetamos o compilamos o lo que fuera necesario git tag a v1 1 2 git log on
25. ile from remote ls BUGS curstextlib h INSTALL languages h Makefile masterm h new_file from remote TODO cursors h HISTORY intl1 LICENSE masterm c new file README utils h cat new file from remote E hola desde el remote git log oneline decorate graph x c502d2e HEAD masterm lang Merge remote tracking branch invernalia masterm lang into masterm lang A 010040b tag v1 1 2 betal invernalia masterm lang agrego un archivo en el remote 8ca28c3 tag v1 1 2 Merge luego de conflicto AA 2f77f01 testing agrego cambio a README de prueba esperando generar conflicto en master 5d2d17e agrego cambio a README esperando generar conflicto cuando haga merge I 97bc9fb tag v1 1 2 beta agrego texto a new file como prueba 4882d44 mis cambios al README y creando new file 14 23c4c4e origin masterm lang origin HEAD removed bianry file Como puede observarse se agrego un nuevo archivo e incluso el rbol de versiones se actualiz con la informaci n que se obtuvo desde el repositorio remoto git merge invernalia test_ remote Merge made by recursive new file from remote 2 1 files changed 2 insertions 0 deletions cat new file from remote hola desde el remoteN linea 2 Y esto integra tambi n a masterm_lang los cambios en el otro branch el de invernalia test_remote origin git fetch merge git pull git push En caso de tener permisos un
26. istradores de proyectos en cuanto a programaci n frameworks de pruebas unitarias y funcionales acordes al lenguaje en que est hecho el proyecto depurardores en cuanto a documentaci n frameworks para documentar c digo y generar documentaci n de APIs wikis y todo un largo etc tera Interfaces para Git git gui sencilla interfaz gr fica portable basada en Tcl Tk es la interfaz gr fica oficial del proyecto gitk interfaz gr fica para visualizar repositorios y sus historiales Tambi n es parte oficial del proyecto ViewGit un navegador de repositorios Git hecho en PHP TortoiseGit para Windows Tower para la Mac IDEs que tienen soporte para Git Eclipse Netbeans Xcode Para saber m s Aqu pongo unos links con m s informaci n sobre Git Manual de usuario de Git en ingl s Tutorial de Git Referencia de Git en ingl s gran parte de la informaci n de este art culo la base en ste gittutorial 7 en ingl s A successful Git branching model en ingl s excelente gu a sobre c mo podr a implantarse un modelo de versionado con branches usando Git en ambientes de desarrollo parte 1 Versionadores parte 3 Github A adir nuevo comentario Default Danland Y Cambiar tema Ut lien aur Auta i l me Aur entuluva The day has come The nightis passing Day shall come again Fingon H rin Thalion J R R Tolkien The Silmarillion Accesibilidad Contacto Acercade Feed Mapa del sitio Lice
27. l nombre de un branch como par metro se usa el nombre dado al tag tambi n se puede usar el identificador de un commit cualquiera Solamente hay que tener cuidado si el lugar al que nos movemos no es un branch espec fico Git entra a un estado en el que la copia de trabajo actual no est en ning n branch y es necesario moverse de ah para continuar trabajando Por ltimo el par metro 1 informar de todos los tags que tenga creados el repositorio git tag 1 v1 1 2 v1 1 2 beta master git branch rama_tag git tag Interactuando con un repositorio remoto Como hasta ahora se ha podido constatar Git no utiliza servidores centrales con los repositorios a la manera de SVN y otros VCS Un VCS distribuido como Git b sicamente genera un nuevo servidor Git por cada clonaci n de un repositorio Git que se haga no hay ninguna diferencia entre el servidor y el cliente ambos son el mismo y utilizan el mismo formato para la informaci n que almacenan Una vez que se tiene un repositorio Git sobre el que versionar alg n proyecto se le puede indicar a Git que sincronice la informaci n de este repositorio con alg n otro repositorio remoto de forma que este ltimo pueda tener los ltimos cambios que se han realizado sobre el repositorio local o que ste se actualice a los ltimos cambios que otros han subido al repositorio remoto Y la ventaja con Git es que no hay necesidad de hacer esto de forma que coincida con ning n com
28. los comandos asociados y despu s si as se desea buscar alguna interfaz diferente m s acorde a los gustos personales Al final de este art culo coloco unos links con algunas interfaces alternativas para Git Lo que s debe quedar claro es que este post es una mera introducci n a Git no pretende ser una gu a exhaustiva del sistema La idea es darlo a conocer promover su uso hacer notar su importancia en proyectos de software libre y dejar la carta abierta para que el interesado investigue m s y se informe de todos los detalles que aqu no se mencionan Para facilitar la lectura de este art culo y que a su vez pueda servir como una peque a referencia introductoria a Git coloco aqu ligas internas a las distintas secciones del mismo a manera de ndice Breve historia de Git El modo Git Generando un repositorio 1 Inicializando un directorio como repositorio Git 2 Copiando un repositorio Git Usando el repositorio local git add git status git diff git commit Branches y Merges git branch checkout git merge Conflictos git log git tag Interactuando con un repositorio remoto git remote git fetch merge pull git push git request pull Conclusi n Interfaces para Git Para saber m s Breve historia de Git Git surgi como un VCS de la mano de Linus Torvalds el creador del kernel Linux para administrar precisamente el c digo de su proyecto estrella Inicialmente el kernel de Linux era administr
29. mit La sincronizaci n es un proceso totalmente diferenciado del versionado y no interfiere con el funcionamiento mismo de versionar el c digo y manejar las versiones del mismo a conciencia En resumen se utiliza git fetch para actualizar el repositorio local con cambios del remoto y git push para enviar los cambios versiones hechas con commit del local al repositorio remoto La administraci n de repositorios remotos se logra con git remote git remote Puesto que en Git un cliente y un servidor es b sicamente lo mismo se pueden tener declarados m s de un repositorio remoto y elegir el que se desee usar en determinado momento por ejemplo tener un repositorio de acceso completo y otro de s lo lectura Al iniciar un repositorio con git init no hay ning n repositorio remoto declarado Sin embargo con git clone el repositorio remoto por default es el de la URL utilizada para clonar el repositorio Por default el nombre de ste repositorio es origin Git utiliza nombres cortos para identificar los repositorios remotos de forma que no tenga que recordarse siempre o estar tecleando la URL de los mismos Con git remote se pueden ver los repositorios remotos que se tienen actualmente dados de alta git remote origin git remote v origin git github com jstitch masterm git fetch origin git github com jstitch masterm git push El par metro v muestra la URL asociada al remoto Git incluso permite tener distintas URLs para un
30. n el branch masterm_lang no existe el cambio de la nueva l nea y el texto hola mundo Pero en el branch testing s que existen estos cambios pues ah se hizo el commit Cambios locales sin a adir al ndice agrego texto a new file como prueba mis cambios al README y creando new file i es origin removed bianry file Added files for brach masterm_lang Added all project files First commit SHA1 ID Buscar T y revisi n que contiene Javier Novoa lt jstil Javier Novoa Cata o Javier Novoa lt jstil Javier Novoa lt jstil Javier Novoa lt jstil Javier Novoa lt jstil Buscar T Diferencia Versi n antigua Versi n nueva Autor Javier Novoa ejstitch invernalia homelinux net gt 2011 07 14 13 27 07 Committer Javier Novoa lt jstitchfBinvernalia homelinux net gt 2011 07 14 13 27 07 Padre 66015510bd5a3da9641362be9b259e553a301ca2 mis cambios al README y creando ne Rama testing 51qgue a Precede a agrego texto a new file como prueba A new_file index e6 de29 e667e6b 100644 eg 0 0 1 2 Gu hola mundo git merge L neas de contexto 3 git branch rama M Ignora cami aj i I I EET E a q I I 1 a r git checkout rama o E i a Fama EA Agregando e ra Fa i 7 archro EF A F Pa Fi histani 7 y e r a 7 FA a g prala Pa Fd ETSIA ELS a A Pa Pl AUS pa y war e Pa Dis e
31. nal como Subversion Git maneja los repositorios y los conceptos mismos de un VCS de una manera particular Mientras que para Subversion el control de versiones se hace archivo por archivo sobre cada directorio que integra un proyecto para Git el control de versiones se hace sobre los distintos snapshots que se tomen de todo el proyecto La diferencia radica en que para sistemas como Subversion cada versi n del proyecto incluye la versi n de cada uno de los archivos del mismo Mientras tanto para Git cada versi n del proyecto incluye solamente un manifiesto con las diferencias de cada archivo es decir de c mo se ve el proyecto en su totalidad en determinado momento Entendiendo Git as ser f cil adaptarse a su modo de funcionamiento e incluso salir de usar un VCS centralizado y comenzar a usar la genial idea que representan los VCS distribuidos myfile txt myfile txt notes txt De manera muy general el siguiente esquema ilustra cada parte del proceso que se usa para versionar con Git origin git remote add git push git fetch merge Agregar un A git pull repositorio remoto git clone git remote git O local ele detal 5 gt remotos se tienen E A Sr Ti resolviendo AA conflictos Agregando editando archivos 22 i git merge Modificado git branch Agregado master eliminaDo Y JA pendiente para Historial Ea t ve
32. ncia Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
33. ra informaci n tambi n aunque ambos branches coincidir an en su log desde el inicio de la existencia del branch padre desde el que se gener el actual hasta el momento en que se cre el branch nuevo Se puede observar que se da informaci n como una clave distinta para identificar cada commit hecho los datos del responsable de tal commit la descripci n dada en su momento E incluso cuando se trata de merge se identifican los commit inmiscuidos Este identificador de los commit se puede usar como par metro a comandos como git diff para comparar el estado actual del proyecto con tal o cual versi n del repositorio en lugar del HEAD git log oneline 8ca28c3 Merge luego de conflicto 5d2d17e agrego cambio a README esperando generar conflicto cuando haga merge 2f77f01 agrego cambio a README de prueba esperando generar conflicto en master 97bc9fb agrego texto a new file como prueba 4882444 mis cambios al README y creando new file 23c4c4e removed bianry file Con el par metro oneline se muestra solamente el identificador corto del commit y la descripci n del mismo para un resumen breve N tese aqu la importancia de buenas descripciones en los commit es la informaci n de la evoluci n del sistema lo que se est describiendo no hay que tomarse a la ligera escribir buenas descripciones git log oneline graph ds 8ca28c3 Merge luego de conflicto IN 2 77f01 agrego cambio a README de prueba esperando generar confl
34. raci n se realiz comunic ndose con alg n servidor ni nada por el estilo cd proyecto git init Initialized empty Git repository in path to proyecto proyecto git git init master 2 Copiando un repositorio Git Ahora supongamos que deseamos colaborar en alg n proyecto o simplemente queremos obtener su c digo fuente para compilarlo y usarlo o para mirarlo y admirarlo Para esto lo primero que hay que hacer es obtener el c digo fuente Si los administradores del proyecto son listos y utilizan Git para el mismo lo que debemos hacer es copiar o clonar el repositorio origen del proyecto para as tenerlo como un repositorio completamente local sobre el cual poder trabajar Los repositorios git tienen una URL y con ella se utiliza el comando git clone url para clonar el repositorio de origen remoto a un repositorio completamente local sobre el cual poder trabajar Por ejemplo git clone git github com jstitch masterm git Cloning into masterm remote Counting objects 36 done remote Compressing objects 100 35 35 done remote Total 36 delta 14 reused 0 delta 0 Receiving objects 100 36 36 49 14 KiB done Resolving deltas 100 14 14 done clonar el repositorio del proyecto que reside en git github com jstitch masterm git al directorio masterm local cd masterm ls BUGS curstextlib h INSTALL languages h Makefile masterm h TODO cursors h HISTORY intl LICENSE masterm
35. rsionar Que Git An E i C mo ve Git versione estos dd o n archivo cambios git checkout L l H l D ENA h ES _ rama fr a k g sargardo reana A p F A a git add 9 ar git status mat itlog ko git diff j ii n PEA g t ai E git lap I ae db r git commit git branch git pull git clone luego de un Sea pull request Y i e a eee L A T master tag git tag Proceso de versionado con Git Generando un repositorio El primer paso para utilizar Git es tener un repositorio El repositorio Git se representa por un directorio especial llamado git y que reside en el directorio ra z del proyecto mismo A diferencia de SVN Git s lo genera un nico directorio para todo el repositorio en donde almacena toda la informaci n del mismo versiones historial etc si se recuerda SVN ste almacena un directorio svn dentro de cada subdirectorio del proyecto versionado almacenando en el mismo esa misma informaci n con otro formato para cada directorio y por lo tanto cada archivo del proyecto Hay dos maneras de generar un repositorio para trabajar con Git sobre un proyecto 1 Inicializando un directorio como repositorio Git Suponiendo que se tiene un directorio en el que reside el proyecto a versionar el comando git init crea el repositorio Git para el proyecto dado Esta generaci n del repositorio es completamente local a la m quina y el directorio donde reside el proyecto Ninguna ope
36. sin explicar c mo funciona B sicamente git status permite conocer la manera en que Git ve los archivos del proyecto con respecto al repositorio La opci n s usada en los ejemplos anteriores dan un status resumido Sin esta bandera la salida ser a mas o menos as On branch masterm lang Changes to be committed use git reset HEAD to unstage modified README new file new file Se de Se e Se 3 Si se puso atenci n en la salida con la bandera s el status aparece con dos columnas La primera indica los cambios que har Git en la siguiente versi n del c digo La segunda columna indica cambios que Git reconoce como tales pero que no versionar echo gt gt new file git status s M README AM new file Como se puede ver aqu luego de una modificaci n al archivo new_file Git sabe que hay modificaciones pero como fueron hechas luego de git ada Git no las tomar en cuenta para la siguiente versi n Observemos la salida no resumida del status git status On branch masterm lang Changes to be committed use git reset HEAD to unstage modified README new file new file Changes not staged for commit use git add to update what will be committed use git checkout to discard changes in working directory modified new file JE dh de de dk Se de Se de e Se e Ur Es decir en la siguiente versi n aparecer n los cambios al archivo README y la aparici n del nuevo archivo
37. to git branch Y git checkout Como ya se insinu m s arriba Al crear un nuevo repositorio en Git por defecto se tiene un nico branch el inicial o principal del proyecto Se le llama master por default El comando git branch lista todos los branches existentes actualmente en un proyecto Siguiendo con el ejemplo de un repositorio clonado previamente desde otro proyecto git branch masterm lang El asterisco muestra cu l es el branch actual o contexto actual en el que se encuentra el proyecto Como puede verse al tratarse de un proyecto clonado desde otro repositorio el branch por default no se llama master pero el punto es que se trata del branch principal del proyecto Para crear un nuevo branch se utiliza el comando git branch nombre del branch git branch testing git branch masterm lang testing Como se puede observar ya existe un nuevo branch en el proyecto testing Este branch est hecho a partir del c digo en su ltimo estado tanto los ltimos commits como los archivos con cambios que han y no han sido a adidos para versionar Y para pasar a ese nuevo contexto y trabajar sobre l se utiliza git checkout nombre del branch git checkout testing git branch masterm lang testing Y como puede observarse ahora es testing el contexto actual sobre el que se trabajar en el proyecto Si hacemos algunos cambios en un archivo y luego regresamos al contexto original masterm_lang como no se
Download Pdf Manuals
Related Search