- RESUMEN

Acerca del Control de Versiones.

Un control de versiones es un sistema que registra los cambios realizados en un archivo o
conjunto de archivos a lo largo del tiempo.
Un sistema de control de versiones (VCS) te permite regresar a versiones anteriores de tus
archivos, regresar a una versión anterior del proyecto completo, comparar cambios a lo
largo del tiempo, ver quién modificó por última vez algo que pueda estar causando
problemas, ver quién introdujo un problema y cuándo, y mucho más. Usar un VCS significa
que si arruinas o pierdes archivos, será posible recuperarlos a un costo muy bajo.

Sistemas de Control de Versiones Locales

Un método de control de versiones, usado por muchas personas, es copiar los archivos
a otro directorio indicando la fecha y hora en que lo hicieron .Este método es muy común
porque es muy sencillo, pero también es propenso a errores. Es fácil olvidar en qué
directorio te encuentras y guardar accidentalmente en el archivo equivocado o sobrescribir
archivos que no querías.
Para afrontar este problema los programadores desarrollaron VCS locales que contenían
una simple base de datos, en la que se llevaba el registro de todos los cambios realizados a
los archivos.

Sistemas de Control de Versiones Centralizados.

Los sistemas de Control de Versiones Centralizados (CVCS) fueron desarrollados para
colaborar con desarrolladores en otros sistemas. Estos sistemas, como CVS, Subversion y
Perforce, tienen un único servidor que contiene todos los archivos versionados y varios
clientes que descargan los archivos desde ese lugar central.
Esta configuración ofrece muchas ventajas, por ejemplo, todas las personas saben que
están trabajando los otros colaboradores del proyecto. Los administradores tienen control
detallado sobre qué puede hacer cada usuario,es mucho más fácil administrar.
pero también tiene sus desventajas, punto único de fallo que representa el servidor
centralizado. Si ese servidor se cae nadie podrá colaborar o guardar
cambios en archivos en los que hayan estado trabajando. Si el disco duro en el que se
encuentra la base de datos central se corrompe, y no se han realizado copias de
seguridad, se perderá toda la información del proyecto, con excepción
de las copias instantáneas que las personas tengan en sus máquinas locales.

Sistemas de Control de Versiones Distribuidos.

Los sistemas de Control de Versiones Distribuidos (DVCS) ofrecen soluciones para los
problemas del CVCS. En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes
descargan la última copia instantánea de los archivos y se replica completamente el
repositorio. Si un servidor deja de funcionar y estos sistemas estaban colaborando a través
de él, cualquiera de los repositorios disponibles en los clientes puede ser copiado al
servidor con el fin de restaurarlo. Cada clon es realmente una copia completa de todos
los datos.

Breve historia de Git.

El kernel de Linux es un proyecto de software de código abierto. Durante el mantenimiento
(1991-2002), los cambios en el software se realizaban a través de parches y archivos. En el
Linux comenzó a usar un DVCS propietario llamado
BitKeeper.
En el 2005, la compañía que desarrollaba BitKeeper dejó de ser gratuita. Esto impulsó a la
comunidad de desarrollo de Linux a desarrollar su propia herramienta
basada en BitKeeper.
Algunos de los objetivos del nuevo sistema fueron los siguientes:
● Velocidad.
● Diseño sencillo.
● Gran soporte para desarrollo no lineal (miles de ramas paralelas).
● Completamente distribuido.
● Capaz de manejar grandes proyectos (como el kernel de Linux) eficientemente
(velocidad y tamaño de los datos).
Desde el 2005, Git ha evolucionado para ser fácil de usar y conservar sus características
iniciales. Es tremendamente rápido, muy eficiente con grandes proyectos y tiene un
increíble sistema de ramificación (branching) para desarrollo no lineal.

Copias instantáneas.
Git maneja sus datos como un conjunto de copias instantáneas de un sistema de
archivos miniatura. Cada vez que confirmas un cambio, o guardas el estado de tu
proyecto en Git, él copia tus archivos en ese momento y guarda una referencia a esa copia
instantánea. De no haberse modificado Git no almacena el archivo de nuevo, sino un enlace
al archivo anterior idéntico que ya tiene almacenado. Git maneja sus datos como una
secuencia de copias instantáneas.
La mayoría de las operaciones en Git sólo necesitan archivos y recursos locales para
funcionar. Debido a que tienes toda la historia del proyecto en tu disco local, la mayoría de
las operaciones parecen prácticamente inmediatas.
La mayoría de las operaciones en Git sólo necesitan archivos y recursos locales para
funcionar.Debido a que tienes toda la historia del proyecto en tu disco local, la mayoría de la
Las operaciones parecen prácticamente inmediatas.
Por ejemplo, para navegar por la historia del proyecto, Git no necesita conectarse al
servidor para obtener la historia y mostrarla -simplemente la lee directamente de tu
base de datos local. Si quieres ver los cambios introducidos en un archivo entre la
versión actual y la de hace un mes, Git puede buscar el archivo de hace un mes y hacer
un cálculo de diferencias localmente,u obtener una versión antigua desde la red y hacerlo
de manera local. Esto también significa que hay muy poco que no puedes hacer si estás
desconectado o sin VPN.
Todo en Git es verificado mediante una suma de comprobación (checksum) antes de ser
almacenado, y es identificado a partir de ese momento mediante dicha suma. Esto significa
que es imposible cambiar los contenidos de cualquier archivo o directorio sin que Git lo
sepa.
El mecanismo que usa Git para generar esta suma de comprobación se conoce como
hash SHA-1. Se trata de una cadena de 40 caracteres hexadecimales (0-9 y a-f), y se
calcula con base en los contenidos del archivo o estructura del directorio en Git. Un
hash SHA-1 se ve de la siguiente forma:
24b9da6552252987aa493b52f8696cd6d3b00373
Verás estos valores hash por todos lados en Git, ya que guarda todo no por nombre de
archivo, sino por el valor hash de sus contenidos.
Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado
(committed), modificado (modified), y preparado (staged). Confirmado: significa que
los datos están almacenados de manera segura en tu base de datos local. Modificado:
significa que has modificado el archivo pero todavía no lo has confirmado a tu base de
datos. Preparado: significa que has marcado un archivo modificado en su versión
actual para que vaya en tu próxima confirmación.
Esto nos lleva a las tres secciones principales de un proyecto de Git: El directorio de Git
(Git directory), el directorio de trabajo (working directory), y el área de preparación
(staging area).
El directorio de Git es donde se almacenan los metadatos y la base de datos de objetos
para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando se
clona un repositorio desde otra computadora.
El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se
sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco
para que los puedas usar o modificar.
El área de preparación es un archivo,que almacena información acerca de lo que va a ir en
tu próxima confirmación. A veces se le denomina índice (“index”).
El flujo de trabajo básico en Git es algo así:
● Modificas una serie de archivos en tu directorio de trabajo.
● Preparas los archivos, añadiendo a tu área de preparación.
● Confirmas los cambios, lo que toma los archivos tal y como están en el área de
preparación y almacena esa copia instantánea de manera permanente en tu directorio de
Git.
Si una versión concreta de un archivo está en el directorio de Git, se considera
confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio,
pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido
cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada
(modified).
Puedes instalarlo como un paquete, a partir de un archivo instalador o bajando el código
fuente y comparándolo tú mismo.
Git trae una herramienta llamada git config, que te permite obtener y establecer variables de
configuración que controlan el aspecto y funcionamiento de Git. Estas variables pueden
almacenarse en tres sitios distintos:
1. Archivo /etc/gitconfig: Contiene valores para todos los usuarios del sistema y todos sus
repositorios. Si pasas la opción --system a git config, lee y escribe específicamente en este
archivo.
2. Archivo ~/.gitconfig o ~/.config/git/config: Este archivo es específico de tu usuario. Puedes
hacer que Git lea y escriba específicamente en este archivo pasando la opción --global.
3. Archivo config en el directorio de Git (es decir, .git/config) del repositorio que estés
utilizando actualmente: Este archivo es específico del repositorio actual.
Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de .git/config
tienen preferencia sobre los de /etc/gitconfig (C:\Users\$USER). También busca el
archivo /etc/gitconfig, aunque esta ruta es relativa a la raíz MSys, que es donde decidiste
instalar Git en tu sistema Windows cuando ejecutaste el instalador.
Lo primero que deberás hacer cuando instales Git es establecer tu nombre de usuario y
dirección de correo electrónico. Porque los "commits" de Git usan esta información, y es
introducida de manera inmutable en los commits que envías:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
Sólo necesitas hacer esto una vez si especificas la opción --global, ya que Git siempre
usará esta información para todo lo que hagas en ese sistema. Si quieres sobrescribir esta
información con otro nombre o dirección de correo para proyectos específicos, puedes
ejecutar el comando sin la opción --global cuando estés en ese proyecto.
Muchas de las herramientas de interfaz gráfica te ayudarán a hacer esto la primera vez
que las uses.

Tu Editor.
Tu identidad está configurada, puedes elegir el editor de texto por defecto que se utilizará
cuando Git necesite que introduzcas un mensaje. Si no indicas nada, Git usará el editor por
defecto de tu sistema, si quieres comprobar tu configuración, puedes usar el comando git
config --list para mostrar todas las propiedades que Git ha configurado:
$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
Puede que veas claves repetidas, porque Git lee la misma clave de distintos archivos
(/etc/gitconfig y ~/.gitconfig, por ejemplo). En estos casos, Git usa el último valor para
cada clave única que ve.
También puedes comprobar el valor que Git utilizará para una clave específica ejecutando
git config <key>:
$ git config user.name
John Doe
Si necesitas ayuda usando Git, existen tres formas de ver la página del manual (manpage)
para cualquier comando de Git:
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
Por ejemplo, puedes ver la página del manual para el comando config ejecutando
$ git help config
Estos comandos son muy útiles porque puedes acceder a ellos desde cualquier sitio,
incluso sin conexión.

Obteniendo un repositorio Git.

Puedes obtener un proyecto Git de dos maneras. La primera es tomar un proyecto o
directorio existente e importarlo en Git. La segunda es clonar un repositorio existente
en Git desde otro servidor.

Inicializando un repositorio en un directorio existente.

Si estás comenzando a seguir un proyecto existente en Git, debes ir al directorio del
proyecto y usar el siguiente comando git init.
Esto crea un subdirectorio nuevo llamado .git, el cual contiene todos los archivos
necesarios del repositorio.
Si deseas comenzar a controlar versiones de archivos existentes, probablemente deberías
comenzar el seguimiento de esos archivos y hacer una confirmación inicial. Puedes
conseguirlo con unos comandos git add para especificar qué archivos quieres controlar,
seguidos de un git commit para confirmar los cambios:
$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'
En este momento, tienes un repositorio de Git con archivos bajo seguimiento y una
confirmación inicial.

Clonando un repositorio existente.

Si deseas obtener una copia de un repositorio Git existente — por ejemplo, un proyecto en
el que te gustaría contribuir — el comando que necesitas es git clone. Si estás familiarizado
con otros sistemas de control de versiones como Subversion, verás que el comando es
"clone" en vez de "checkout".
Git recibe una copia de casi todos los datos que tiene el servidor. Cada versión de cada
archivo de la historia del proyecto es descargada por defecto cuando ejecutas git clone.
Puedes clonar un repositorio con git clone [url]. Por ejemplo, si quieres clonar la librería de
Git llamada libgit2 puedes hacer algo así:
$ git clone https://github.com/libgit2/libgit2
Esto crea un directorio llamado libgit2, inicializa un directorio. Verás que están los archivos
del proyecto listos para ser utilizados. Si quieres clonar el repositorio a un directorio con
otro nombre que no sea libgit2, puedes especificarlo con la siguiente opción de línea de
comandos:
$ git clone https://github.com/libgit2/libgit2 mylibgit
Este comando hace lo mismo que el anterior, pero el directorio de destino se llamará
mylibgit.
Git te permite usar distintos protocolos de transferencia. El ejemplo anterior usa el protocolo
https://, pero también puedes utilizar git:// o usuario@servidor:ruta/del/repositorio.git que
utiliza el protocolo de transferencia SSH.
Ya tienes un repositorio Git y un checkout o copia de trabajo del proyecto. El siguiente paso
es realizar algunos cambios y confirmar instantáneas de esos cambios en el repositorio
cada vez que el proyecto alcance un estado que quieras conservar. Cada archivo de tu
repositorio puede tener dos estados: rastreados y sin rastrear. Los archivos rastreados
(tracked files) son todos aquellos archivos que estaban en la última instantánea del
proyecto; pueden ser archivos sin modificar, modificados o preparados. Los archivos sin
rastrear son todos los demás - cualquier otro archivo en tu directorio de trabajo que no
estaba en tu última instantánea y que no está en el área de preparación (staging area).
Cuando clonas por primera vez un repositorio, todos tus archivos estarán rastreados y sin
modificar pues acabas de sacarlos y aún no han sido editados.
Mientras editas archivos, Git los ve como modificados, pues han sido cambiados desde
su último commit. Luego preparas estos archivos modificados y finalmente confirmas
todos los cambios preparados, y repites el ciclo.

Revisando el Estado de tus Archivos.

La herramienta principal para determinar qué archivos están en qué estado es el comando
git status. Si ejecutas este comando inmediatamente después de clonar un repositorio,
deberías ver algo como esto:
$ git status
On branch master
nothing to commit, working directory clean
Esto significa que tienes un directorio de trabajo limpio, que no hay archivos rastreados y
modificados. El comando te indica en cuál rama estás y te informa que no ha variado con
respecto a la misma rama en el servidor, la rama siempre será “master”, que es la rama por
defecto.
Supongamos que añades un nuevo archivo a tu proyecto, un simple README. Si el archivo
no existía antes y ejecutas git status, verás el archivo sin rastrear de la siguiente manera:
$ echo 'My Project' > README
$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)
El archivo README está sin rastrear porque aparece debajo del encabezado “Untracked
files” (“Archivos no rastreados”) en la salida. Sin rastrear significa que Git ve archivos que
no tenías en el commit anterior. Git no los incluirá en tu próximo commit a menos que se lo
indiques explícitamente. Se comporta así para evitar incluir accidentalmente archivos
binarios o cualquier otro archivo que no quieras incluir. Como tú sí quieres incluir README,
debes comenzar a rastrearlo.

Rastrear Archivos Nuevos.

Puedes usar el comando git add y en nombre del archivo para rastrearlo. Al usarlo veras en
el estado del proyecto que en archivo aparece como rastreado. Puedes ver que está siendo
rastreado porque aparece luego del encabezado “Cambios a ser confirmados” (“Changes to
be committed”). Si confirmas en este punto, se guardará en el historial la versión del archivo
correspondiente al instante en que ejecutamos git add. Anteriormente cuando ejecutaste git
init, ejecutaste luego git add.
El comando git add puede recibir tanto una ruta de archivo como de un directorio; si es de
un directorio, el comando añade recursivamente los archivos que están dentro de él.
Git add es un comando que cumple varios propósitos: para rastrear archivos nuevos,
preparar archivos, y hacer otras cosas como marcar “resuelto” archivos en conflicto por
combinación.

Ignorar Archivos.
A veces, hay tipos de archivos que no quieres que Git añada automáticamente o que ni
siquiera aparezca como no rastreado, para ello podemos utilizar el comando .gitignore.
La primera línea le indica a Git que ignore cualquier archivo que termine en “.o” o “.a” -
archivos de objeto o librerías que pueden ser producto de compilar tu código. La segunda
línea le indica a Git que ignore todos los archivos que terminan con una tilde (~), la cual es
usada por varios editores de texto como Emacs para marcar archivos temporales. También
puedes incluir cosas como trazas, temporales, o pid directamente; documentación generada
automáticamente; etc. Crear un archivo .gitignore antes de comenzar a trabajar es
generalmente una buena idea, ya que evitas confirmar accidentalmente archivos que en
realidad no quieres incluir en tu repositorio Git.
Las reglas sobre los patrones que puedes incluir en el archivo .gitignore son las siguientes:
● Ignorar las líneas en blanco y aquellas que comienzan con #.
● Aceptar patrones glob estándar.
● Los patrones pueden terminar en barra (/) para especificar un directorio.
● Los patrones pueden negarse si se añade al principio el signo de exclamación (!).
Los patrones glob son una especie de expresión regular simplificada usada por los
terminales. Un asterisco (*) corresponde a cero o más caracteres; [abc] corresponde a
cualquier carácter dentro de los corchetes; el signo de interrogación (?) corresponde a un
carácter cualquiera; y los corchetes sobre caracteres separados por un guión ([0-9])
corresponde a cualquier carácter entre ellos. También puedes usar dos asteriscos para
indicar directorios anidados; a/**/z coincide con a/z, a/b/z, a/b/c/z, etc.

Ver los Cambios Preparados y No Preparados.

Puedes usar el comando git diff, este te muestra las líneas exactas que fueron añadidas y
eliminadas, es decir, el parche.
Supongamos que editas y preparas el archivo README de nuevo y luego editas
CONTRIBUTING.md pero no lo preparas. Si ejecutas el comando git status, no veras lis
cambios.
Para ver qué has cambiado pero aún no has preparado, escribe git diff sin más parámetros,
este comando compara lo que tienes en tu directorio de trabajo con lo que está en el área
de preparación. El resultado te indica los cambios que has hecho pero que aún no has
preparado. Al llamar a git diff sin parámetros no verás los cambios desde tu última
confirmación - solo verás los cambios que aún no están preparados. Esto puede ser
confuso porque si preparas todos tus cambios, git diff no te devolverá ninguna salida.
Si quieres ver lo que has preparado y será incluido en la próxima confirmación, puedes usar
git diff --staged, compara tus cambios preparados con la última instantánea confirmada.

Confirmar tus cambios.

Cuando tu área de preparación está como quieres, puedes confirmar tus cambios, cualquier
cosa que no esté preparada - cualquier archivo que hayas creado o modificado y que no
hayas agregado con git add desde su edición - no será confirmado. Se mantendrán como
archivos modificados en tu disco. La forma más sencilla de confirmar es escribiendo git
commit.
Al hacerlo, arrancará el editor que se establece a través de la variable de ambiente
$EDITOR de tu terminal, puedes configurar el editor que quieras usando el comando git
config --global core.editor.
El mensaje de confirmación contiene la última salida del comando git status comentada y
una línea vacía encima de ella. Puedes eliminar estos comentarios y escribir tu mensaje de
confirmación, o puedes dejarlos allí para ayudarte a recordar qué estás confirmando.
Cuando sales del editor, Git crea tu confirmación con tu mensaje.
Otra alternativa es escribir el mensaje de confirmación directamente en el comando commit
utilizando la opción -m.
la confirmación te devuelve una salida descriptiva: indica cuál rama has confirmado
(master), que checksum SHA-1 tiene el commit (463dc4f), cuántos archivos han cambiado y
estadísticas sobre las líneas añadidas y eliminadas en el commit.La confirmación guarda
una instantánea de tu área de preparación.
Si quieres saltarte el área de preparación, Git te ofrece un atajo sencillo. Añadiendo la
opción -a al comando git commit harás que Git prepare automáticamente todos los archivos
rastreados antes de confirmarlos, ahorrándote el paso de git add.

Eliminar Archivos.
Para eliminar archivos de Git, debes eliminarlos de tus archivos rastreados del área de
preparación y luego confirmar.Usa el comando git rm, que además elimina el archivo de tu
directorio de trabajo de manera que no aparezca la próxima vez como un archivo no
rastreado.Si modificaste el archivo y ya lo habías añadido al índice, tendrás que forzar su
eliminación con la opción -f. Esta propiedad existe por seguridad, para prevenir que elimines
accidentalmente datos que aún no han sido guardados como una instantánea y que por lo
tanto no podrás recuperar luego con Git.
Otra cosa que puedas mantener el archivo en tu disco duro pero sin que Git lo siga
rastreando, para hacerlo, utiliza la opción --cached. Al comando git rm puedes pasarle
archivos, directorios y patrones glob.

Cambiar el Nombre de los Archivos.

Git no rastrea explícitamente los cambios de nombre en archivos. Si renombrar un archivo
en Git, no se guardará ningún metadato que indique que renombramos el archivo.git usa el
comando mv para renombrar.

Ver el Historial de Confirmaciones.

Para ver modificaciones se han llevado a cabo después de haber hecho varias
confirmaciones o clonar un repositorio que ya tenía un histórico de confirmaciones. Usar el
comando git log.Por defecto, si no pasas ningún parámetro, git log lista las confirmaciones
hechas sobre ese repositorio en orden cronológico inverso, las confirmaciones más
recientes se muestran al principio. Este comando lista cada confirmación con su suma de
comprobación SHA-1, el nombre y dirección de correo del autor, la fecha y el mensaje de
confirmación.
El comando git log proporciona gran cantidad de opciones para mostrarte exactamente lo
que buscas.Una es la opción -p, que muestra las diferencias introducidas en cada
confirmación. También puedes usar la opción -2, que hace que se muestren únicamente las
dos últimas entradas del historial.Esta opción muestra la misma información, pero
añadiendo tras cada entrada las diferencias que le corresponden. Esto resulta muy útil para
revisiones de código, o para visualizar rápidamente lo que ha pasado en las confirmaciones
enviadas por un colaborador.
Puedes usar la opción --stat para ver algunas estadísticas de cada confirmación.Otras
opciones son short, full y fuller, que muestran la salida en un formato parecido, pero
añadiendo menos o más información, respectivamente.
La opción online imprime cada confirmación en una única línea, lo que puede resultar útil si
estás analizando gran cantidad de confirmaciones.
Otra opción es --pretty, que modifica el formato de la salida.La opción más interesante es
format, que te permite especificar tu propio formato.Las opciones oneline y format son
especialmente útiles combinadas con otra opción llamada --graph. Ésta añade un pequeño
gráfico ASCII mostrando tu historial de ramificaciones y uniones.

Deshacer Cosas.
a veces no es posible recuperar algo luego que lo has deshecho. Esta es una de las pocas
áreas en las que Git puede perder parte de tu trabajo si cometes un error.
Una de las acciones más comunes a deshacer es cuando confirmas un cambio antes de
tiempo y olvidas agregar algún archivo, o te equivocas en el mensaje de confirmación. Si
quieres rehacer la confirmación, puedes reconfirmar con la opción --amend.
Este comando utiliza tu área de preparación para la confirmación. Si no has hecho cambios
desde tu última confirmación, entonces la instantánea lucirá exactamente igual y lo único
que cambiarás será el mensaje de confirmación.
Se lanzará el mismo editor de confirmación, pero verás que ya incluye el mensaje de tu
confirmación anterior.

Trabajar con Remotos.

Los repositorios remotos son versiones de tu proyecto que están hospedadas en Internet o
en cualquier otra red. Puedes tener varios de ellos, y en cada uno tendrás generalmente
permisos de solo lectura o de lectura y escritura. Colaborar con otras personas implica
gestionar estos repositorios remotos enviando y trayendo datos de ellos cada vez que
necesites compartir tu trabajo. Gestionar repositorios remotos incluye saber cómo añadir un
repositorio remoto, eliminar los remotos que ya no son válidos, gestionar varias ramas
remotas, definir si deben rastrearse o no y más.

Ver Tus Remotos.

Para ver los remotos que tienes configurados, debes ejecutar el comando git remote.
Mostrará los nombres de cada uno de los remotos que tienes especificados. Si has clonado
tu repositorio, deberías ver al menos origin (origen),nombre que por defecto Git le da al
servidor del que has clonado. Puedes pasar la opción -v, la cual muestra las URLs que Git
ha asociado al nombre y que serán usadas al leer y escribir en ese remoto. Si tienes más de
un remoto, el comando los listará todos.

Añadir Repositorios Remotos.

Para añadir un remoto nuevo y asociarlo a un nombre que puedas referenciar fácilmente,
ejecuta git remote add [nombre] [url].
A partir de ahora puedes usar el nombre del repositorio en la línea de comandos en lugar de
la URL entera. Por ejemplo, si quieres traer toda la información que tiene ese repositorio
pero tú aún no tienes en tu repositorio, puedes ejecutar git fetch pb.

Traer y Combinar Remotos.

El comando irá al proyecto remoto y se traerá todos los datos que aún no tienes de dicho
remoto. Luego, tendrás referencias a todas las ramas del remoto, las cuales puedes
combinar e inspeccionar cuando quieras.
Si clonas un repositorio, el comando de clonar automáticamente añade ese repositorio
remoto con el nombre “origin”. Git fetch origin se trae todo el trabajo nuevo que ha sido
enviado a ese servidor desde que lo clonaste, no lo combina automáticamente con tu
trabajo ni modifica el trabajo que llevas hecho. La combinación con tu trabajo debes hacerla
manualmente cuando estés listo.
Si has configurado una rama para que rastree una rama remota, puedes usar el comando
git pull para traer y combinar automáticamente la rama remota con tu rama actual. Al
ejecutar git pull traerás datos del servidor del que clonaste originalmente y se intentará
combinar automáticamente la información con el código en el que estás trabajando.

Enviar a Tus Remotos.

Cuando tienes un proyecto que quieres compartir, debes enviarlo a un servidor con el
comando git push [nombre-remoto] [nombre-rama].Si quieres enviar tu rama master a tu
servidor origin entonces puedes ejecutar el comando git push origin master y se enviarán
todos los commits que hayas hecho al servidor.
Este comando solo funciona si clonaste de un servidor sobre el que tienes permisos de
escritura y si nadie más ha enviado datos por el medio. Si alguien más clona el mismo
repositorio que tú y envía información antes que tú, tu envío será rechazado. Tendrás que
traer tu trabajo y combinarlo con el tuyo antes de que puedas enviar datos al servidor.

Inspeccionar un Remoto.
Si quieres ver más información acerca de un remoto en particular, puedes ejecutar el
comando git remote show [nombre-remoto].
El comando lista la URL del repositorio remoto y la información del rastreo de ramas. El
comando te indica claramente que si estás en la rama maestra y ejecutas el comando git
pull, automáticamente combinará la rama maestra remota con tu rama local, luego de haber
traído toda la información de ella. También lista todas las referencias remotas de las que ha
traído datos.

Eliminar y Renombrar Remotos.

Si quieres cambiar el nombre de la referencia de un remoto puedes ejecutar git remote
rename.al hacer esto también cambias el nombre de las ramas remotas master.
Si por alguna razón quieres eliminar un remoto - has cambiado de servidor o no quieres
seguir utilizando un mirror o quizás un colaborador ha dejado de trabajar en el proyecto -
puedes usar git remote rm.

La Rama.
Para entender realmente cómo ramifica Git, previamente hemos de examinar la forma en
que almacena sus datos.
Git no los almacena de forma incremental (guardando sólo diferencias), sino que los
almacena como una serie de instantáneas (copias puntuales de los archivos completos, tal
y como se encuentran en ese momento).
En cada confirmación de cambios (commit), Git almacena una instantánea de tu trabajo
preparado. Contiene además unos metadatos con el autor y el mensaje explicativo, y uno o
varios apuntadores a las confirmaciones (commit) que sean padres directos de esta (un
padre en los casos de confirmación normal, y múltiples padres en los casos de estar
confirmando una fusión (merge) de dos o más ramas).
por ejemplo, que tienes una carpeta con tres archivos, que preparas (stage) todos ellos y los
confirmas (commit). Al preparar los archivos, Git realiza una suma de control de cada uno
de ellos (un resumen SHA-1, tal y como se mencionaba en Inicio - Sobre el Control de
Versiones), almacena una copia de cada uno en el repositorio (estas copias se denominan
"blobs"), y guarda cada suma de control en el área de preparación (staging area).
Cuando creas una confirmación con el comando git commit, Git realiza sumas de control de
cada subdirectorio, y las guarda como objetos árbol en el repositorio Git. Después, Git crea
un objeto de confirmación con los metadatos pertinentes y un apuntador al objeto árbol raíz
del proyecto.
En este momento, el repositorio de Git contendrá cinco objetos: un "blob" para cada uno de
los tres archivos, un árbol con la lista de contenidos del directorio (más sus respectivas
relaciones con los "blobs"), y una confirmación de cambios (commit) apuntando a la raíz de
ese árbol y conteniendo el resto de metadatos pertinentes.
Si haces más cambios y vuelves a confirmar, la siguiente confirmación guardará un
apuntador a su confirmación precedente.
Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones.
La rama por defecto de Git es la rama master. Con la primera confirmación de cambios que
realicemos, se creará esta rama principal master apuntando a dicha confirmación. En cada
confirmación de cambios que realicemos, la rama irá avanzando automáticamente.

Crear una Rama Nueva.

Para ello, usarás el comando git branch y nombre de rama. Esto creará un nuevo apuntador
apuntando a la misma confirmación donde estés actualmente.
mediante un apuntador especial denominado HEAD, es simplemente el apuntador a la rama
local en la que tú estés en ese momento, en este caso la rama master; pues el comando git
branch solamente crea una nueva rama, pero no salta a dicha rama.

Cambiar de Rama.
Para saltar de una rama a otra, tienes que utilizar el comando git checkout.Esto mueve el
apuntador HEAD a la rama nombrada y realizar otra confirmación de cambios.
Observamos que la rama nombrada avanza, mientras que la rama master permanece en la
confirmación donde estaba cuando lanzaste el comando git checkout para saltar.
Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama master,
y revierte los archivos de tu directorio de trabajo; dejándolos tal y como estaban en la última
instantánea confirmada en dicha rama master. Esto supone que los cambios que hagas
desde este momento en adelante, divergieron de la antigua versión del proyecto.
Básicamente, lo que se está haciendo es rebobinar el trabajo que habías hecho
temporalmente en la rama nombrada; de tal forma que puedas avanzar en otra dirección
diferente.
Puedes saltar libremente de una a otra según estimes oportuno. Y todo ello simplemente
con tres comandos: git branch, git checkout y git commit.
También puedes ver esto utilizando el comando git log. Si ejecutas git log --oneline --
decorate --graph --all te mostrará el historial de tus confirmaciones, indicando dónde están
los apuntadores de tus ramas y como ha divergido tu historial.

Procedimientos Básicos de Ramificación.

Imagina que estás trabajando en un proyecto y tienes un par de confirmaciones (commit) ya
realizadas.
Decides trabajar en el problema #53, según el sistema que tu compañía utiliza para llevar el
seguimiento de los problemas. Para crear una nueva rama y saltar a ella, en un solo paso,
puedes utilizar el comando git checkout con la opción -b.
Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Con ello
avanzas la rama iss53, que es la que tienes activada (checked out) en este momento (es
decir, a la que apunta HEAD).
Entonces, recibes una llamada avisándote de otro problema urgente en el sitio web y debes
resolverlo inmediatamente. Al usar Git, no necesitas mezclar el nuevo problema con los
cambios que ya habías realizado sobre el problema #53; ni tampoco perder tiempo
revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción.
Basta con saltar de nuevo a la rama master y continuar trabajando a partir de allí.
Pero, antes de poder hacer eso, hemos de tomar en cuenta que si tenemos cambios aún no
confirmados en el directorio de trabajo o en el área de preparación, Git no nos permitirá
saltar a otra rama con la que podríamos tener conflictos. Lo mejor es tener siempre un
estado de trabajo limpio y despejado antes de saltar entre ramas. Como tenemos
confirmados todos los cambios, podemos saltar a la rama master sin problemas.
Tras esto, tendrás el directorio de trabajo exactamente igual a como estaba antes de
comenzar a trabajar sobre el problema #53 y podrás concentrarte en el nuevo problema
urgente. Es importante recordar que Git revierte el directorio de trabajo exactamente al
estado en que estaba en la confirmación (commit) apuntada por la rama que activamos
(checkout) en cada momento.
A continuación, es momento de resolver el problema urgente. Creando una nueva rama
hotfix, una nueva rama hotfix, sobre la que trabajar hasta resolverlo.
Puedes realizar las pruebas oportunas, asegurarte de que la solución es correcta, e
incorporar los cambios a la rama master para ponerlos en producción con el comando git
merge. Aparecerá la frase “Fast forward” (“Avance rápido”) en la salida del comando. Git ha
movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has
fusionado estaba directamente arriba respecto a la confirmación actual. Dicho de otro modo:
cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo
directamente el historial de la primera; Git simplifica las cosas avanzando el puntero, ya que
no hay ningún otro trabajo divergente a fusionar. Esto es lo que se denomina “avance
rápido” (“fast forward”).
Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación
(commit) apuntada por la rama master. Y puedes desplegarlos.
Tras haber resuelto el problema urgente que había interrumpido tu trabajo, puedes volver a
donde estabas. Pero antes, es importante borrar la rama hotfix, ya que no la vamos a
necesitar más, puesto que apunta exactamente al mismo sitio que la rama master. Esto lo
puedes hacer con la opción -d del comando git branch.Y, con esto, ya estás listo para
regresar al trabajo sobre el problema #53.
Cabe destacar que todo el trabajo realizado en la rama hotfix no está en los archivos de la
rama iss53. Si fuera necesario agregarlos, puedes fusionar (merge) la rama master sobre la
rama iss53 utilizando el comando git merge master, o puedes esperar hasta que decidas
fusionar (merge) la rama iss53 a la rama master.

Procedimientos Básicos de Fusión.

Supongamos que tu trabajo con el problema #53 ya está completo y listo para fusionarlo
(merge) con la rama master. Para ello, de forma similar a como antes has hecho con la
rama hotfix, vas a fusionar la rama iss53. Simplemente, activa (checkout) la rama donde
deseas fusionar y lanza el comando git merge
Debido a que la confirmación en la rama actual no es ancestro directo de la rama que
pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres
bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas
y por el ancestro común a ambas.
En lugar de simplemente avanzar el apuntador de la rama, Git crea una nueva instantánea
(snapshot) resultante de la fusión a tres bandas; y crea automáticamente una nueva
confirmación de cambios (commit) que apunta a ella. Nos referimos a este proceso como
"fusión confirmada" y su particularidad es que tiene más de un padre.
Vale la pena destacar el hecho de que es el propio Git quien determina automáticamente el
mejor ancestro común para realizar la fusión; a diferencia de otros sistemas tales como CVS
o Subversion, donde es el desarrollador quien ha de determinar cuál puede ser dicho mejor
ancestro común. Esto hace que en Git sea mucho más fácil realizar fusiones.
Ahora que todo tu trabajo ya está fusionado con la rama principal, no tienes necesidad de la
rama iss53. Por lo que puedes borrarla y cerrar manualmente el problema en el sistema de
seguimiento de problemas de tu empresa.

Principales Conflictos que Pueden Surgir en las Fusiones.

Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos
ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente.
Git no crea automáticamente una nueva fusión confirmada (merge commit), sino que hace
una pausa en el proceso, esperando a que tú resuelvas el conflicto. Para ver qué archivos
permanecen sin fusionar en un determinado momento conflictivo de una fusión.
Todo aquello que sea conflictivo y no se haya podido resolver, se marca como "sin fusionar"
(unmerged). Git añade a los archivos conflictivos unos marcadores especiales de resolución
de conflictos que te guiarán cuando abras manualmente los archivos implicados y los edites
para corregirlos.

Gestión de Ramas.
El comando git branch tiene más funciones que las de crear y borrar ramas. Si lo lanzas sin
parámetros, obtienes una lista de las ramas presentes en tu proyecto.
$ git branch
iss53
* master
testing
Fijate en el carácter * delante de la rama master: nos indica la rama activa en este momento
(la rama a la que apunta HEAD). Si hacemos una confirmación de cambios (commit), esa
será la rama que avance. Para ver la última confirmación de cambios en cada rama, puedes
usar el comando git branch -v.
$ git branch -v
iss53 93b412c fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
Otra opción útil para averiguar el estado de las ramas, es filtrarlas y mostrar solo aquellas
que han sido fusionadas o no con la rama actualmente activa.Para ello, Git dispone de las
opciones --merged y --no-merged.