git, el control de versiones definitivo (por ahora)

Wed, 2007-10-31 21:34 — david.villa

Una pequeña introducción a git, el sistema de control de versiones de moda.

Ingredientes

git-core – fast, scalable, distributed revision control system

Identidad del usuario

Para las operaciones de log, git necesita una identificación del usuario, para ello usa estos dos comandos:

$ git config [—global] user.email “juan.nadie@babia.es” $ git config [—global] user.name “Juan Nadie”

Creando un repositorio

Partiendo de un directorio (sea nuevo o no):

juan@example:~/iexplorer9$ git init Initialized empty Git repository in .git/

Añadir contenido

Lo primero es añadir el propio directorio donde has inicializado el repositorio:

juan@example:~/iexplorer9$ git add .

Y después, del mismo modo puedes añadir cualquier fichero que crees en ese directorio o en los que contiene.

Commit

Como en la mayoría de los VCS (Version Control System) para hacer que los cambios sean permanentes y se cree una nueva versión es necesario ejecutar un “commit”. La sintaxis en git es obvia:

juan@example:~/iexplorer9$ git commit

Y como también es habitual, pide un mensajito para informar al prójimo del propósito de los cambios realizados. Y aquí viene “la pregunta”: ¿dónde han ido esos cambios si no has indicado en ningún momento el servidor? Pues esa es una diferencia fundamental con CVS o Subversion, no tiene porqué haber un servidor que mantenga el repositorio, CVS y Subversion eran centralizados, git es distribuido.

En resumen, todo lo anterior es para crear y mantener un repositorio personal individual.

Descargar una copia del repo

Evidentemente git tendría poco interés si no diera la posibilidad de que varias personas trabajaran sobre el mismo repositorio. Otro usuario “pepe” que tenga cuenta en la misma máquina puede obtener una copia del repo de juan con:

pepe@example:~$ git clone /home/juan/iexplorer9 micopia

Trabajo en equipo

Pepe puede ahora hacer cambios sobre su copia del repo. El usuario Juan puede integrar esos cambios en su repo con:

juan@example:~/iexplorer9$ git pull /home/pepe/micopia

Si Juan va a realizar esta operación frecuentemente y además quiere tener un control más fino de los cambios puede utilizar un mecanismo alternativo:

juan@example:~/iexplorer9$ git remote add pepe /home/pepe/micopia juan@example:~/iexplorer9$ git fetch pepe

A diferencia de pull, el comando fetch crea una rama, que se puede mezclar con la rama principal:

juan@example:~/iexplorer9$ git merge pepe/master

o lo que es lo mismo:

juan@example:~/iexplorer9$ git pull . remotes/pepe/master

Modo “centralizado”

En el apartado anterior, los cambios se piden siempre explícitamente. Hay otra alternativa: el comando push que permite trabajar de una forma similar a la que se utiliza CVS o Subversion. En ese caso, Pepe puede enviar sus cambios a la copia de Juan con:

pepe@example:~/micopia$ git push

Y puede actualizar su copia con:

pepe@example:~/micopia$ git pull

Acceso remoto

Es posible obtener una copia desde otra máquina mediante SSH:

manolo@box:~$ git clone ssh://example.org/~juan/iexplorer9

También es posible acceder remotamente con WebDAV y rsync

Referencias

david.villa's blog
Login or register to post comments
20838 reads

Comments

Thu, 2008-01-10 18:36 — javieralso

Cuestiones varias (sobre Git)

Buenas, me he montado un repositorio Git en el ordenador de casa, por ésto de organizar un poco mas mis cosas y por ver qué tal es git, que me lo han vendido muy “bonito” y subversión ya lo conozco…

El caso es que tengo cuestiones varias:

Accediendo remotamente con SSH ¿Cómo hago para poder utilizar otro puerto que no sea el 22? Tengo el servicio SSH redireccionado a otro puerto y no consigo averiguar cómo decirle a git que utilice dicho puerto cuando lo uso remotamente con SSH

Git lo tengo en casa como repositorio centralizado, pero no puedo trabajar sobre la copia local de mis datos. Quiero decir que tuve que coger el directorio original, copiarlo en una carpeta (a la que llamé “repos”), montar ahí el repo y una vez hecho eso hacer un clone a otro directorio desde donde trabajar. Si trabajaba en el directorio donde tenía los datos originales del repo y hacía un push, me decía que esa no era una copia local y no me dejaba. Además, los cambios que realizo en cualquiera de las copias locales, tras subirlos, aparecen en el directorio donde hice el clone, pero no en el original desde el que creé el repo ¿eso es así? ¿hay forma de utilizar el directorio original del repo como copia de trabajo también?

¿Como puedo hacer para permitir el acceso a los repos a distintos usuarios según me convenga?

¿Tengo que hacer necesariamente git commit y después git push para subir los cambios? ¿No hay una manera mas “resumida”?

He estado trasteando por ahí y no he encontrado gran cosa, así que lo pregunto por aquí y así nos sirve para todos. Por otro lado, tengo que decir que de momento, no me está llendo del todo mal la experiencia con git, aunque aún no le he metido demasiada “tralla”.

Ya iré viendo después

—

The cause of the problem is:
The vendor put the bug there.
-- Meta amigo informático --

Sat, 2008-01-12 22:22 — paco

Algunas respuestas

Usar otro puerto u otro login.

Lo más fácil es tener un .ssh/config en el que pongas algo como

Host myHost
    HostName myHost.myDomain
    Port 2222
    User pepe.lopez

Así puedes tener repos del estilo ssh://myHost/~/git/myRepo.git.

Para usarlo como repo centralizado con copia local.

El caso que expones es similar al de Using git for collaboration del tutorial de GIT, así que aplica los mismos truquitos.

Acceso a otros usuarios.

Hay muchas formas, algunas se comentan en plan receta en la sección Repository Administration de Everyday GIT with 20 commands or so

Manera resumida de git commit y git push.

Facil: alias push=‘git commit -a && git push —all’

Fri, 2007-11-02 11:51 — Raúl S. Siles (not verified)

Mercurial, no tan conocido pero de gran calidad.

Cuando oigo hablar de git me chirría algo por dentro. No es que no me guste git, del que soy usuario asiduo y cuyo canal IRC de soporte está muy por encima de lo normal en cuanto a calidad.

Lo que ocurre es que cuando se dice git muchas veces lo que se quiere decir es sistema de control de versiones distribuido. No digo que sea en este caso en concreto en el que se confundan ambos términos.

Git es un ejemplo y muy bueno de sistema de control de versiones distribuido, pero no es el único. Existen varios, entre ellos bazaar, monotonic o darcs. Pero de todos ellos yo me quedo con mercurial.

Este sistema ha sido adoptado entre otros por el proyecto alsa o xine. Su canal de soporte también es magnífico y no tiene nada que envidiar a git en cuando a funcionalidades.

Aproximarse a mercurial viniendo de un sistema centralizado como subversion es más sencillo que a git. Su comunidad no para de mejorarlo, incorporar nuevas características y no tienen ninguna vergüenza en copiar cualquier cosa que suponga una mejora y esto incluye a cualquier otro sistema de control de versiones. Su documentación al igual que en caso de git también es excelente.

Es una joyita y además te ahorras un 33% al escribir su nombre en línea de comandos, véase git vs hg

Sobra decir que todo esto es una humilde opinión y sin ánimo de desmerecer el artículo que no tiene ninguna pega en cuanto a introducción a git.

Sun, 2007-11-04 00:00 — david.villa

Uno de tantos

Lo cierto es que últimamente han salido VCS hasta de debajo de las piedras. En la wikipedia hay una buena comparativa de VCS. Se acabaron los tiempos en los que CVS era el estándar absoluto, pero bueno, la diversidad siempre es positiva.

Por cierto, muy interesante también SVK que es un sistema descentralizado/distribuido basado en Subversion y también mr que permite usar repositorios de varios sistemas al mismo tiempo.

—
En este mundo jodío,
cada uno va a su avío,
menos yo que voy al mío

—

No soy portavoz de ningún colectivo, grupo o facción. Mi opinión es personal e intransferible.

Fri, 2007-11-02 14:07 — magmax