EvaMC

Aplicaciones necesarias:

  • Git: software de control de versiones de aplicaciones diseñado por Linus Torvalds
  • SourceTree: herramienta para trabajar con sistemas de versionado de forma gráfica
  • Editor de Markdown: lenguaje de marcado que facilita la escritura de HTML
  • Pandoc: conversor de documentos, para convertir los archivos Markdown en HTML

Configuración GIT

# Ver la versión instalada de Git
git --version
# Cambiar la configuración global
git config --global user.name "Mi nombre"
git config --global user.email "mi@email.es"
# Cambiar los colores de la consola
git config --global color.ui true
# Cambiar el editor por defecto a nano
git config --global core.editor "nano"
# Consulta de los parámetros guardados
git config user.name
git config user.email

Crear repositorio

# Crear y acceder al directorio en el que estará el código
mkdir miproyecto
cd miproyecto
# Para convertir la carpeta en un repositorio de Git
git init
# Se ha creado una carpeta oculta .git
# Si eliminamos la carpeta .git dejará de ser un repositorio

Las tres zonas de Git

  1. Working Copy: es el directorio donde estamos trabajando, donde están nuestros archivos
  2. Staging Area: donde vamos a poner los archivos de los que queremos guardar las versiones (trackear, también conocido como área index o caché)
  3. Repository: donde se almacena toda la información de los cambios

Desde nuestro SO sólo veremos el Working Copy, para ver los otros dos usaremos comandos Git

Primeros pasos

Usar git status para saber:

  • qué archivos están en el Staging Area y cuales no
  • qué archivos son trackeados
  • qué archivos han sido modificados

Del Working Copy al Staging Area: con git add <file>, git add <folder> o git add *.txt

Para deshacer los cambios del Working Copy: git checkout — <file>

Para sacar un archivo del Staging Area: git reset HEAD <file> o <folder> o *.txt

Del Staging Area al Repositorio: con git commit -m «Mensaje descriptivo» o sólo git commit

Un commit es un paquete que contiene:

  • Uno o más «hunks» (el resultado de un diff). Se crea un hunks por archivo.
  • Un mensaje que describe qué cambios van en este commit. Hay que describirlo bien.
  • Un hash SHA para identificar el commit
  • Un enlace con su «commit padre»

Si modificamos un archivo y hacemos un git add pero no un git commit, y luego volvemos a modificar el archivo, tendremos que hacer el git add y el git commit de nuevo.

Si eliminamos un archivo físicamente tendremos que hacer el git add del archivo borrado, o con git rm <file> Git lo elimina y lo poner en el Staging Area automáticamente.

El comando git log nos sirven para ver los commits que se han realizado.

Con el comando git diff podremos ver las diferencias entre las diferentes zonas:

* Nota: git diff –cached es lo mismo que git diff –staged

Introducción a Markdown y Pandoc

Pandoc: con pandoc <file.md> se muestra en pantalla el resultado de la conversión de markdown a html, y con pandoc <file.md> > <file.html> se crea el fichero en HTML.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *