Thefull

Sacado de :  Aprendizaje 
Cuando implementamos el problema del JCajero durante el curso de TDD usamos nuestras cuentas de GitHub para compartir el código entre las parejas del equipo.
gitYo tengo una cuenta de GitHub desde que empecé mi camino de aprendiz de Ruby. Decidí abrirla para ir alojando los ejemplos de código. Pero a pesar de ello, no me puse a aprender a utilizar Git en condiciones.Va siendo hora de cambiar eso. Este post inaugura una serie en la que iré explicando lo que voy aprendiendo de este SCM. Serán sólo los conceptos básicos para utilizarlo en el día a día, porque hay mucho que rascar.
Para los que estéis interesados en seguir mis pasos, deciros que lo primero que hice fue ver la presentación de James Gregory sobre Git en la NDC2010. Me parece una muy buena formade empezar y ver Git en funcionamiento.
Ahora estoy siguiendo un ebook, gratuito en su momento, titulado Getting Good With Git. Es bastante breve y se lee muy fácil. Pero tiene la pega de tener que ir completando ciertas cosas por tu cuenta. Además tiene una sección dedicada específicamente a GitHub.
Lo primero que tenemos que saber de Git es que es un sistema de control de versionesdistribuído. A simple vista no parece una gran ventaja. Suena a simple decisión de diseño. En realidad esta característica ofrece muchas ventajas:
No necesitas una conexión de internet ni un servidor ejecutándose en local para disponer de un SCM. Tienes tu repositorio completo con un sólo comando.
Se puede compartir código de una forma muy, muy sencilla. No estamos limitados a tener nuestrorepositorio en local y uno remoto en GitHub. Podemos tener todos los repositorios remotos que queramos. Incluso sincronizarnos con los repositorios locales de nuestros compañeros de equipo.
Al contrario que en los sistemas de control de versiones centralizados,prácticamente todas las operaciones son locales. Se trabaja en local siempre salvo para subir los cambios a, o, obtener los cambios de, unrepositorio remoto. Esto tiene un gran impacto en el rendimiento, consiguiendo que todas las operaciones sean prácticamente instantáneas.
Dependiendo de tu sistema operativo podrás instalarlo de una u otra manera. Lo mejor que podéis hacer es ir a la web oficial de git y mirar cuál es la mejor forma de instalarlo en vuestro caso.
Una vez instalado, comprobad que el ejecutable está en vuestro PATH.Si os fijáis en la página de inicio de la web de git, aparecen dos formas de crear un nuevo repositorio: creando uno en local o clonando uno remoto. Yo voy a empezar a hablar de como trabajar en local.
Vamos a comenzar por crear un repositorio:
Creando un repositorio local en git
Mediante la sentencia git init hemos creado un nuevo repositorio en el directorio actual. También podríamos haberespecificado un nombre de directorio que se hubiera creado a la vez que el repositorio, en el caso de no existir.
Si os fijáis se ha creado un directorio .git en nuestro directorio de trabajo. Ese directorio almacenará toda la información del repositorio. No ocurrirá como con SVN, por ejemplo, que tendremos un directorio .svn en todos y cada uno de los directorios que existan en nuestrorepositorio.
Mediante git status podemos conocer el estado actual de nuestro repositorio:
Git status en un repositorio vacío
Vamos a crear un par de archivos vacíos y ver qué cambia:
Git status con archivos nuevos
Si queremos que git ignore ciertos archivos o directorios no tenemos más que crear un archivo .gitignore y añadir su path relativo ahí. Los nombres pueden incluir wildcards como ‘*’ y‘?’. Por ejemplo: *.swp o archivo?
Este archivo forma parte de nuestro repositorio y también será versionado por git.
Veamos que ocurre si creamos nuestro .gitignore y añadimos archivo1 a la lista de archivos a ignorar:
Ignorando archivo1
En el próximo post seguiré desarrollando este ejemplo y hablaré del staging areay de cómo hacer commit de nuestros cambios.

0
Públicado el 24/12/2010...