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
- Working Copy: es el directorio donde estamos trabajando, donde están nuestros archivos
- Staging Area: donde vamos a poner los archivos de los que queremos guardar las versiones (trackear, también conocido como área index o caché)
- 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.