PDF de programación - Versionando con Git y Github

1;2802;0c

Página personal de JStitch

Buscar en este sitio: 

Login

Register

  Buscar

COLECCIONES

PORTAFOLIOS

LINKS

Inicio
Versionando con Git y Github ­ Parte 2
Enviado por JStitch el Mar, 12/07/2011 ­ 10:42.

0

 

o Cómo Introducirse al Software Libre siendo Programador

Esta 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 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 administrado 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  tradicional  (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.

De manera muy general, el siguiente esquema ilustra cada parte del proceso que se usa para versionar con Git:

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
operació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/

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.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:
$ ls ­a
./ BUGS curstextlib.h HISTORY intl/ LICENSE masterm.c README utils.h
../ cursors.h .git/ INSTALL languages.h Makefile masterm.h TODO

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 echarle la culpa  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 [email protected]

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 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