0% encontró este documento útil (0 votos)
336 vistas14 páginas

Git para Dummies

Cargado por

chikipunker
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
336 vistas14 páginas

Git para Dummies

Cargado por

chikipunker
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 14

Git para dummies

Disclaimer: Ese post ni es, ni lo pretende, ser un tutorial de Git. Es simplemente


las impresiones de alguien (yo) que ayer empezó a usar, por primera vez, Git.
Seguro que hay gente que lee ese blog y que sabe mucho, pero mucho más de
Git que yo… Así que sus comentarios y correcciones serán bienvenidas!

Esos días (ayer, vamos :p) he empezado a usar Git. Para quien no lo conozca Git
es un sistema de control de código fuente distribuido. A diferencia de TFS, VSS o
SVN que son centralizados, en Git cada desarrollador tiene su propia copia entera
del repositorio en local. Los cambios son propagados entre repositorios locales y
pueden (o no) sincronizarse con un repositorio central.

La diferencia fundamental con TFS ó VSS es que en esos está claro quién es el
repositorio (el servidor). Eso no existe en Git. En Git cada usuario es el repositorio
y se sincronizan cambios entre repositorios (usuarios). Opcionalmente puede
usarse un repositorio central pero parece que no es obligatorio.

Los cambios en Git se propagan a través de esas operaciones:

1. commit: Envia los datos del working directory al repositorio local

2. push: Sincroniza los cambios del repositorio local a otro repositorio remoto.

3. fetch: Sincroniza los cambios de un repositorio remoto al repositorio local.

4. pull: Sincroniza los cambios de un repositorio remoto al working directory.

5. checkout: Actualiza el workind directory con los datos del repositorio local.

Usar Git desde Visual Studio

Para usar Git desde VS2010 he encontrado las Git Extensions que instalan, no
sólo un plugin para VS2010, sinó también el propio Git y clientes adicionales que
pueden necesitarse (SSH o PuTTY si queremos conexiones seguras con nuestros
repositorios).

Una vez instaladas nos aparecerá un menú nuevo llamado “Git” en el VS2010.
Crear un repositorio local y rellenarlo

Para empezar a trabajar con Git, lo primero es crear un repositorio. Recordad


que los repositorios son locales, por lo que un repositorio es simplemente un
directorio de nuestro disco. En mi caso, tenía ya una solución de VS2010 en
local que es la que quería empezar a compartir con Git. Por ello lo que hice fue
crear un nuevo repositorio local. Hay otra opción, que es crear un repositorio local
a partir de los datos de un repositorio remoto (git-clone) pero todavía no lo he
hecho. Si todo va como está planeado, el viernes tocará hacerlo, y ya escribiré al
respecto!

Usando las Git Extensions crearnos nuestro propio repositorio es tan sencillo
como usar la opción “Initialize new repository” y nos saldrá una ventana como la
siguiente:

La opción normal es “Personal repository”. Un Central repository es un repositorio


sin Working directory, que sólo sirve para sincronizar datos.

Una vez entrada la carpeta (en este caso D:Gittest) esa pasa a ser el directorio
de trabajo (working directory) para ese repositorio. Si abrimos la carpeta con el
explorador de windows veremos que hay una carpeta en su interior llamada .git:
ese es el repositorio local.

Nota: Dado que el directorio donde inicializamos el repositorio local pasa a ser
el directorio de tabajo, lo suyo es inicializar el repositorio local en el mismo
directorio donde tenemos la solución de VS. Es decir, si la solución de VS la
tenemos en el directorio C:projectssourcemyproject, ese sería el directorio que
usariamos (recordad que el repositorio se crea en una subcarpeta llamada .git, por
lo que no modificarà ni borrará nada de la carpeta que le digáis).
En mi caso en D:Gittest ya tenía una solución, por lo que el árbol de directorios me
ha quedado:

Ahora vamos a hacer commit de la solución al repositorio local. Antes que nada,
pero debemos tener presente de que no queremos que todos los archivos que
cuelgan del working directory (D:gittest) se guarden en el repositorio local. Git no
entiende de tipos de archivo, no sabe que es código fuente y que no. Existe un
fichero en el working directory llamado .gitignore que sirve para indicar que
ficheros no deben guardarse en el repositorio local al hacer un commit.

Por suerte editar este fichero con las Git Exensions, es trivial. Nos vamos al menú
Git y seleccionamos “Edit .gitignore”. Nos aparecerá una ventana parecida a:
A la izquierda el contenido del .gitignore (en este caso vacío, normal ya que ni
existe el fichero). A la derecha un ejemplo de .gitignore adaptado a VS. Si pulsais
el botón “add default” os copiará las entradas de la derecha a la izquierda:

Fijaos que el .gitignore se ha confiugrado para evitar archivos como *.exe, *.pdb,
etc, pero también directorios como TestResult* (que usa VS para guardar los
resultados de las pruebas unitarias) o _Resharper* (que usa resharper para
guardar sus configuraciones). Nosotros podríamos añadir más entradas y
finalmente darle a “Save”. Eso nos creará el archivo .gitignore en nuestro working
directory (D:gittest).
Ahora estamos listos para hacer el commit y rellenar por primera vez el repositorio
local. Para ello, de nuevo nos vamos al menú Git y seleccionamos “Commit”. Nos
aparecerá una ventana parecida a:

Se divide en cuatro secciones:

1. Izquierda superior: listado de operaciones pendientes de realizar (cambios


entre el working directory y el repositorio local)

2. Izquierda inferior: listado de operaciones que se van a realizar (es decir


cuales de los cambios del working directory queremos propagar al
repositorio local).

3. Derecha superior: preview del archivo seleccionado en la parte (1).

4. Derecha inferior: comandos de Git.

En este caso vamos a propagar todos los cambios, para ello pulsamos el botón
“Staged Files” y en el menú desplegable marcamos “Stage all”. Con eso todos los
ficheros de la izquierda superior pasarán a la izquiera inferior. Ahora vamos a
realizar el commit (si quisieramos podríamos hacer también un push a un
repositorio remoto pero todavía no hemos configurado ninguno). Así que
entramos un mensaje de commit en la parte derecha inferior (p.ej. commit inicial) y
le damos al botón “Commit”. Git Extensions nos mostrará al final un diálogo con el
resumen de lo hecho:
Añadir cambios

Bien, una vez hemos hecho el commit podemos seguir trabajando con VS2010 sin
necesidad de hacer nada especial. Olvidaros de conceptos como “proteger” o
“desproteger” de TFS o VSS. Simplemente trabajáis y modificáis el contenido del
directorio de trabajo.

Cuando decidáis propagar los cambios del directorio de trabajo al repositorio local,
repetís la operación de antes: Git –> Commit.

Repositorio remoto

Bien, ha llegado la hora de configurar un repositorio remoto. Para ello, lo primero


que necesitamos es tener acceso a un repositorio remoto. Hay varios
proveedores de repositorios Git en internet, entre los que destaca GitHub. GitHub
pero está limitado a proyectos open source. Si neceistáis un hosting de Git para
proyectos no open source hay varios de pago (con algunas versiones gratuitas).
En esta consulta de StackOverflow hablan de ello: Best git repository hosting for
commercial project.

Nota: A título informativo os diré que yo me dí de alta en el plan gratuito de


Assembla, que te da 2GB de espacio Git.

La configuración de un repositorio remoto dependerá de donde lo tengamos, pero


básicamente son dos pasos muy simples:

1. Generar el par clave pública-privada para ssh o PuTTY y subir la clave


pública al repositorio (si queremos acceso seguro).

2. Ponerle a Git Extensions la URL del repositorio remoto.


Vamos a ver una demostración. Para independizarnos de cualquier proveedor,
vamos a crear otro repositorio de Git en nuestra máquina (podríamos hacerlo en
una carpeta compartida p.ej.) y lo usaremos como repositorio remoto.

Para ello de nuevo nos vamos al menú Git y le damos a “Initialize new repository”
y ahora marcamos la opción de Central Repository. Y ponemos cualquier path
nuevo que creemos (en mi caso he creado una carpeta D:Remote):

Si ahora vamos a D:Remote veremos que allí tenemos el repositorio. En este caso
el repositorio no está en un subdirectorio .git, porque hemos elegido la opción de
Central repository que no tiene directorio de trabajo.

Bien, ahora vamos a hacer un push de nuestro repositorio local al repositorio


remoto. Para ello, primero, debemos dar de alta este repositorio remoto en las Git
Extensions. Para ello nos vamos al menú Git y seleccionamos la opción de
“Manage Remotes”. Nos aparecerá una ventana y ponemos los datos:

El nombre es un nombre identificativo, mientras que la URL en este caso es la


carpeta donde está el repositorio. Finalmente le damos a “Save” para guardarlo.
Ahora ya podemos hacer un push para pasar los datos del repositorio local al
remoto. Para ello, de nuevo nos vamos al menú Git y marcamos la opción Push.
En la ventana que nos aparece marcamos la opción “Remote” y de la combo
seleccionamos el repositorio remoto que dimos antes de alta:

Luego pulsamos el botón Push. Como antes nos mostrará un diálogo cuando haya
finalizado:

Navegar por repositorios

Podemos navegar por un repositorio, usando la opción “Browse” del menú Git.
Seleccionamos el repositorio y podemos navegar, ver los commits/push que se
han realizado y ver los archivos y cambios contenidos en cada commit/push. De
todos modos sólo he visto como hacer esto en repositorios (locales o remotos) que
estén en disco. No sé como navegar por mi repositorio en Assembla p.ej.
Y aquí lo dejamos por el momento… A medida que trabaje y que vaya
aprendiendo como funciona Git iré poniendo más información al respecto!

Espero que este post os haya sido útil y que en todo caso haya servido para
que veáis que es Git y las diferencias con otros sistemas de control de código
fuente como TFS.

Un saludo!

git para
dummies
1. ¿Qué es git?

Es importante dejar claro que git no es lo mismo que GitHub, git es un


sistema de control de versiones Open Source creado en el año 2005 por Linus
Torvalds, el creador de Linux, por otro lado GitHub es un servicio de
alojamiento para proyectos versionados con git, de esta forma podemos
tener una copia local y una remota de nuestros repositorios.
Con git podemos entre otras cosas: tener un control de ediciones
versionadas, regresar a versiones anteriores de nuestros proyectos, revisar el
registro de cambios y crear ramas experimentales o mejoras paralelas al
proyecto troncal.

2.Instalación
Primero debes descargar e instalar la versión de git para tu sistema operativo
desde https://git-scm.com/downloads

Para comprobar que la instalación fue realizada en la terminal de comandos


escribes git --version, si fue instalado verás la versión de tu instalación de git.

3.Configuración básica
Es importante configurar al menos un nombre de usuario y un correo
electrónico, para ello escribes en la terminal git config --global user.name ‘tunombre’,
pasando entre comillas tu nombre de usuario y git config --global user.email tuemail
pasando sin comillas tu email.

4.Inicializar un repositorio
Para que la carpeta de un proyecto en tu equipo pase a ser un repositorio de
git debes inicializarla, en la terminal debes posicionarte en la carpeta del
proyecto y escribir git init, esto creará una carpeta oculta de nombre .git la
cual contiene toda la información del versionamiento.

A continuación se hace necesario


comprender los estados de git en
nuestro repositorio local y los
comando necesarios para
movernos entre ellos.
En la imagen de referencia se describen tres estados: el working directory,
este es el sistema de archivos en el cual trabajamos, el staging area, un área
temporal en el que añadimos los archivos cuyos cambios estamos por enviar
a git y el repository, donde se versiona nuestro trabajo.

5.Añadir archivos, status y commit


Para añadir cambios al staging area, lo haces con git add . para incluir los
cambios realizados en todos tus archivos y git add archivo.txt si lo que quieres es
incluir los cambios de un archivo en particular. Para comprobar el estado de
los archivos escribimos git status, de esta forma sabrás cuales están en el
staging area listo para ser enviados al repositorio.

Para añadir los cambios que están en espera al repositorio escribes git commit -
m ‘Mensaje que explique la función del commit’, con el flag -m pasa un mensaje entre
comillas que entregue detalles del cambio añadido, el commit crea puntos de
control en la línea de tiempo de tu repositorio. Para utilizar un solo comado y
realizar el git add + git commit puedes utilizar el flag -a, de la siguiente
manera git commit -a -m ‘Mensaje que explique la función del commit’.

Si agregaste algún cambio al staging area pero quieres quitarlo de ahí puedes
escribir git reset HEAD archivo.txt

6.Ignorar y borrar archivos


En cada proyecto hay archivos que no deseas versionar ya sea por su peso o
su formato, para esto es que git te permite crear el archivo .gitignore dentro
del cual debes detallar las carpetas o archivos que serán ignorados. A
continuación un ejemplo.

Para borrar los cambio realizados en un archivo, en otras palabras regresar a


su última versión guardada o si
borraste por error un archivos
que ya había sido enviado en
un commit antes y quieres
restaurarlo debes escribir en la
línea de comandos git checkout archivo.txt, entonces git lo regresará a su última
versión.

Si lo que quieres es borrar un archivo del repositorio debes ejecutar el


comando git rm archivo.txt, en el próximo commit el archivo será removido.

7.Usando ramas
Con el comando git log puedes ver el historial de commits enviados al
repositorio con los datos del usuario que los realizó, un ID único y el
comentario de referencia que explica su función. Si lo que deseas es
retroceder hasta una versión ‘x’, solo debes escribir en la terminal el
siguiente comando git checkout IdCommit donde IdCommit son los primeros 7
caracteres del ID proporcionado en el log. Para crear una rama de desarrollo
desde ese punto o desde donde te encuentras debes ejecutar git checkout -b
NombreRama

Ahora te encuentras en otra rama, puedes crear cuantas quieras y pasa saber
sus nombre y navegar luego entre ellas es que puedes ejecutar git branch

Es importante mencionar que la rama troncal tiene por nombre master. Si lo


que necesitas es regresar de una rama a master o simplemente moverte de
una rama a otra ejecutas git checkout NombreRama

Para subir tu rama local al repositorio remoto (en el cual la rama no esta
creada), ejecutas git push origin NombreRama, este comando se utiliza con más
frecuencia para subir los cambios realizados en el repositorio local, luego
darles commit, hacia el repositorio remoto. Para traer los cambios que otro
integrante del equipo subió en una rama a tu repositorio local ejecutas git pull
origin NombreRama, puedes traer cambios tu misma rama en su version remota
o de otra rama con la cual quieras actualizar la tuya.

En el caso de querer borrar una rama, ejecutas git branch -D NombreRama


forzando el borrado de una rama sin haber ejecutado antes un merge. Para
fusionar dos ramas o hacer un merge, debes estar sobre la rama que quieres
que permanezca (ej: hacer un merge de un feature a la rama develop) y
ejecutas el comando git merge NombreRama donde NombreRama el nombre de la
rama que queremos integrar. Luego podemos si lo deseas, puedes borrar la
rama ejecutando git branch -d NombreRama

8.Repositorio remoto
GitHub es una de la posibilidades que tienes para crear tu repositorio de
forma remota. Para ello debes crear un repositorio, darle un nombre y si
quieres escribes una descripción. El comando que te permite asociar tu
repositorio local (previamente inicializado) con el remoto es: git remote add
origin https://github.com/nombre-usuario/nombre-repositorio.git luego para subir el
repositorio local ejecutas git push -u origin master, origin master es como se
nombra a este repositorio remoto.

Si lo que deseas es descargar tu repositorio en otro equipo puedes clonar tu


repositorio remoto con el comando: git clone
https://github.com/nombre-usuario/nombre-repositorio.git

Por último ya que alguien más del equipo de desarrollo pudo haber subido
algún cambio, para no estar trabajando en una versión desactualizada debes
bajar la última actualización de tu repositorio remoto a tu local, esto se hace
con git pull origin master. Pull trae los cambio y push los envía.

9.Resumen de comandos git


comando función
git init inicializa un repositorio
git add agrega cambios a staging area
git status muestra el estado de los cambios
git reset HEAD elimina un cambio del staging area
git commit envía un cambio del staging al repositorio
git rm borra cambio del repositorio
git checkout trae la última versión del cambio, crea y cambia de rama
git branch muestra las ramas
git merge fusiona las ramas
git remote add origin relacionar repo local a un repo remoto
git clone clonar repositorio remoto
comando función
git pull trae la última versión del repo remoto
git push envía los cambios al repo remoto

10.Resumen comandos consola


comando función
pwd (unix) - cd (windows) muestra el directorio actual
cd + directorio cambio de directorio
ls (unix) - dir (windows) listar archivos del directorio
cd .. sube un directorio

También podría gustarte