Apuntes de lecturas (readings)
Lectura: «Pro Git» ―Scott Chacon & Ben Straub
Fuente(s):
chacon-et-al.pro-git_2ed.bk.pdf.
1. Getting Started
Acerca del Control de versiones
-
Los sistemas de control de versiones (version control systems - VCS) son sistemas que registran los cambios en el tiempo de un conjunto de ficheros, permitiendo recuperar cualquier estado específico (versión) de los mismos, en cualquier momento.
-
Aunque solemos usar dichos sistemas para almacenar código fuente, en realidad se puede utilizar para cualquier tipo de fichero.
-
Los VCS facilitan la ejecución de las siguientes tareas:
- Revertir el estado de nuestros ficheros a una versión anterior.
- Revertir un proyecto entero a un estado anterior.
- Comparar dos (2) versiones específicas anteriores, para identificar los cambios en el tiempo.
- Conocer rápidamente cuáles han sido los últimos cambios, con miras a identificar qué está causando un problema determinado.
- Saber quién ha realizado qué cambios.
- Otras operaciones a conocer más adelante.
-
Para proporcionar todas estas facilidades el VCS deberá incurrir en algo de overhead, pero el beneficio obtenido a cambio compensa dicha utilización de recursos.
-
Los VCS pueden ser locales, centralizados o _distribuidos.
Los VCS locales
-
Los VCS locales almacenan la información necesaria para desempeñar su función, en forma de ficheros locales, p.e.:
-
La forma más primitiva de control de versiones puede ser trabajar cada proyecto en una carpeta, y almacenar los cambios de los ficheros mediante una copia local, probablemente almacenada cerca de la versión actual y con un nombre que haga referencia a la fecha del cambio.
-
Algunos sistemas derivados de UNIX también disponen de un sistema más avanzado de control de versiones que el anterior, este es el RCS.
-
Los VCS centralizados
-
Por su parte, los VCS centralizados proporcionan los servicios de control de versiones implementando un control centralizado en donde se almacenan todos los datos (y metadatos) en un único servidor.
-
El origen de los VCS centralizados es la necesidad de que varias personas pudieran trabajar sobre un mismo proyecto de manera colaborativa.
-
Este tipo de sistemas, en los que además todos saben en qué trabaja cada quién en determinado momento, facilitan las labores de administración y resguardo de los activos del proyecto.
-
Por el contrario, un VCS centralizado representa un único punto de falla, lo cual detiene el trabajo por completo en caso de desastres, hasta que el servidor pueda ser restaurado nuevamente.
Los VCS distribuidos
-
Al momento de escribir estas notas, el estado del arte de los VCS son los llamados: VCS distribuidos.
-
En los VCS distribuidos los clientes de un repositorio no sólo tienen una fotografía de la versión actual de los ficheros del proyecto, sino que almacenan una copia total del repositorio origen.
-
Adicionalmente, mediante el uso de los VCS distribuidos, se puede trabajar sobre un mismo proyecto almacenado en distintos repositorios, uno para cada grupo de trabajo o propósito.
Una historia corta de Git
-
El origen de Git se debe las desavenencias entre la Fundación Linux y la empresa que hasta entonces proporcionaba BitKeeper. A partir de este acontecimiento, Linus Torvals decidió escribir Git con el objetivo de satisfacer las siguientes necesidades:
- Proporcionar una mayor velocidad de trabajo.
- Un diseño más simple.
- Soporte total al desarrollo no-lineal (miles de ramas paralelas).
- Un estilo totalmente distribuido.
- Capacidad para gestionar proyectos realmente grandes (como es el caso del Kernel de Linux).
-
A partir del 2005, Git ha evolucionado hasta convertirse en el sistema más popular en la actualidad.
2. Git Basics
TODO
3. Git Branching
TODO
4. Git on the Server
TODO
5. Distributed Git
TODO
6. Github
TODO
7. Git Tools
TODO
8. Customizing Git
TODO
9. Git and Other Systems
TODO
10. Git Internals
TODO
A. Git in Other Environments
TODO
B. Embedded Git in Your Applicatioons
TODO
C. Git Commands
TODO
Temas específicos (topics)
Submodulos
Fuentes:
-
Los submódulos de git permiten incorporar código de otros proyectos en nuestro proyecto, manteniendo una historia separada pero sincronizada en nuestro propio repositorio.
-
Esta es una manera sencilla de resolver los problemas de dependecias de código de otros proyectos, aunque en algunos casos no se trata de la mejor opción.
Apuntes de cursos (courses)
Codecademy: «Learn Git»
TODO
StackSkills: «Git Complete: The Definitive, Step-By-Step Guide»
Fuente(s):
Git Installation
Para instalar Git en Windows, vía Scoop, debemos ejecutar:
C:\> sudo scoop install -g git
Notas:
- El comando anterior instalará git de manera global.
- Para poder utilizar el comando
sudo, debemos instalar las herramientas de psutils
TODO
Procedimientos y tareas comunes (tasks)
Mostrar cambios o diferencias (diff)
Cambios en nuestro directorio de trabajo (working directory)
$ git diff
Cambios en nuestra área de montaje (staging area)
$ git diff --staged
Cambios en nuestro repositorio local (local repository)
$ git diff <commit-id>^!
En donde <commit-id> es el identificar de commit con el cual queremos hacer la comparación.
Inicializar un proyecto en Github
$ git clone https://github.com/user/repository.git
…or create a new repository on the command line
echo “# repository” » README.md git init git add README.md git commit -m “first commit” git remote add origin https://github.com/user/repository.git git push -u origin master
…or push an existing repository from the command line
git remote add origin https://github.com/user/repository.git git push -u origin master
…or import code from another repository
You can initialize this repository with code from a Subversion, Mercurial, or TFS project.
Github’s verified commit
TODO