git init

Git es un conocido Sistema de Control de Revisiones Distribuido (DRCS) que permite hacer seguimiento de cambios a los archivos de un proyecto, facilitando además el trabajo en equipo.

Estas son notas preliminares para iniciarse en la terminología git , un panorama para facilitar el camino al que recién se inicia.

Para ejecutar los comandos citados de ejemplo se debe tener git instalado.


Conceptos Básicos

• Repositorio (alias 'repo')
  Lugar donde se almacena el registro de los cambios en archivos, ¿Todos los cambios? no, sólo se registrarán las modificaciones que ocurrieron entre comandos commit, git almacena todo este registro en una carpeta llamada .git
  Para crear un repositorio local se hace con el comando

  git init

  en la misma carpeta que están los archivos que queremos hacer seguimiento.
  Durante el desarrollo y las pruebas se suele trabajar con esos respositorios locales, que están en la misma carpeta de cada proyecto, pero usualmente hay también algún respositorio remoto para mantener las revisiones en un servidor, lo cual es muy útil para trabajar en equipo y tener backup, ahí se suben los cambios y se puede mantener actualizada la copia local con la del server.
  
  Todo esto requiere alguna metodología de trabajo para evitar perder datos, por ejemplo sobreescribir el trabajo de otro, tomar una revisión vieja por error, etc.


• Working Directory / Working Tree
  Es la carpeta donde están todos los archivos de nuestro proyecto. Respecto a git ve básicamente dos tipos de archivos: los que figuran en el repo y se les hace un seguimiento de cambios (tracked) y los que no (untracked) que no se registran. De todas formas esto es dinámico, además hay una instancia intermedia antes de estar registrados en el repo pasan por la "Index/Staging Area".


• The Index/The Staging Area
  Se refiere a la lista de archivos cuyos cambios se registrarán en el repo durante el próximo commit (independientemente de si previamente figuraban o no en el repo) por ejemplo el comando

  git add archivo.txt

  agrega el archivo.txt a la "Staging Area" es decir lo deja 'preparado', y con el comando

  git commit

  se registra en el repo, ya sea su primer registro o almacenando una nueva revisión de sus cambios.
  

  git add .  (agrega al Index los archivos en carpeta, modificados y nuevos, sin actualizar los borrados)
  git add -u . (agrega al Index modificados y actualiza borrados, sin agregar los nuevos)
  git add --all . ( agrega todos los cambios al Index, es decir ambas anteriores)
  



• Commit
  Este es el comando (y concepto) de registrar en el repositorio local la revisión actual de los archivos que estén preparados, es decir, los que están en el Index/Staging Area.
  Para saber qué cambios hubo en la carpeta de trabajo desde el último commit, puede usarse

  git status

  esto informa de los cambios, no sólo en los archivos tracked(que ya figuraban en el repo y tenemos un registro, o de los que estén en el Index listos para commit), sino que justamente nos avisa si por ejemplo aparecieron archivos nuevos en el Working Tree cuyos cambios no están siendo seguidos, para que nos demos cuenta de agregarlos si es necesario.
  Cada commit debe incluir un mensaje que indique el motivo del mismo, por ejemplo "reparado tal problema", "agregada tal función", etc.. además este mensaje queda almacenado en el commit junto al nombre de quien lo hizo. Para listar la historia de commits se usa

  git log

  (y para ver sólo el último commit se puede usar git log -1 ). El nombre de "autor" para los commits se puede especificar globalmente, así no tenemos que escribirlo cada vez en nuestra computadora
  

  git config --global user.name  "nombre"
  git config --global user.email "nombre@mail.com"
  

  También puede abrirse el archivo de configuración con el editor por defecto
  

  git config --global --edit

y editarlo directamente

[user]
         name=nombre
         email=nombre@mail.com



• Staging
  Es la acción de agregar archivos al Index/Staging Area, en otros sistemas la palabra commit suele significar "guardar las diferencias de todos los archivos seguidos" pero en git está la opción/obligación de agregar primero los archivos al Index antes de hacer commit, esto permite commits separados y diferentes para un mismo conjunto de archivos, por ejemplo si se hicieron un par de cambios que no tienen nada que ver entre sí en diferentes archivos, y no se desea hacer un commit general, se pueden hacer varios commit independientes por archivo (e incluso para partes de un mismo archivo).
  Al momento de almacenar los cambios git commit a secas no actualiza todos los archivos del repo, sino sólo los que están en el Index, por lo tanto antes de un commit se deben agregar, por ejemplo, git commit archivo, y si se quieren registrar los cambios de todos los archivos que figuran en el repo, se puede usar el comando git commit -a que primero agrega al Index todos los archivos que ya figuraban en el repositorio (tracked) y después hace el commit. Finalmente si se agregan nuevos archivos al proyecto, y se los desea incluir en el commit, no alcanza con hacer commit -a ya que los que nunca estuvieron en el repositorio se deben agregar mediante add.


• Branch
  En un proyecto suele haber varias ramas de trabajo, se suelen hacer muchas revisiones hasta que queda funcionando(o alguna parte) de una manera más o menos "estable", en esos momentos se libera una Versión, la cual no debe mezclarse con otras revisiones que se puedan ir haciendo ya sea para agregar funciones, reparar errores, probar nuevas características, etc.. cada una de estas posibles ramificaciones de revisiones sucesivas se llama branch, usualmente hay una rama principal a la que se llama master, que es la que contiene sólo las versiones liberadas "estables" y ninguna revisión en la que se estan haciendo cambios "inestable" (pero todo esto ya depende de la metodología de trabajo adoptada)
  Para crear una rama de trabajo, por ejemplo llamada "ramaTrabajo", se usan los comandos:
  

  git branch ramaTrabajo
  git checkout ramaTrabajo

  El primer comando crea el nuevo branch, el segundo lo selecciona. Seleccionar el branch con checkout no es una simple cuestión de nombres, detrás cambia todo, por ejemplo si hicimos modificaciones y commits en la ramaTrabajo, y luego volvemos al branch master, todos los archivos cambian al modo que estaban en master, esto permite cambiar el marco de trabajo sin mezclar revisiones. Si intencionalmente deseo mezclar las revisiones lo voy a hacer a través de git de una forma ordenada, por ejemplo si hay un branch "fix" hecho para corregir un problema, cuando ya está listo para ser parte del master puedo escribir.
  

  git merge fix



• HEAD
  Es una forma de referir el branch actual, con el que se está trabajando, cuando se hace un commit por defecto se guardan las diferencias respecto a la anterior revisión que corresponda a ese branch.
  Por ejemplo el HEAD de un repositorio local podría apuntar a un branch llamado "develop", mientras el HEAD de otro repositorio podría apuntar a un branch llamado "bug_fix", etc..
  Para ver donde está apuntando el branch actual basta ver el contenido del archivo HEAD, esto se puede hacer, estando en la carpeta de trabajo.
  
  En Linux:

  cat .git/HEAD

  En Windows:

  type .git\HEAD



• origin
  Es la forma de referir al repo del servidor remoto desde el cual se actualizado el repo local (pull) o hacia el cual se guardan los cambios (push).
  

  git remote add origin direccion_web_del_repo

  Ejemplo:
  

  git remote add origin https://github.com/nombreUsuario/proyecto.git



• SHA1
  Esto está relacionado a git sólo de manera indirecta, SHA (Secure Hash Algorithm) es la forma que usa git para calcular una "firma" del archivo, identificarlo y detectar así si hubo modificaciones

Para finalizar diagrama simplificado de estos conceptos (fuente:Wikipedia)