¿Cómo instalar y usar GIT?

Git es un sistema de control de versiones distribuido, creado por Linus Torvalds en 2005. Permite rastrear cambios en archivos, coordinar el trabajo entre múltiples personas, volver a versiones anteriores y gestionar ramas de desarrollo.

A diferencia de sistemas centralizados (como Subversion), cada copia del repositorio contiene todo el historial completo, lo que lo hace rápido, flexible y resistente a fallos.

## 31.1. Introducción a Git

En el contexto de la administración de sistemas, Git se utiliza cada vez más para gestionar configuraciones (Infraestructura como Código), scripts y documentación. El examen LFCS puede incluir tareas básicas de Git: inicializar un repositorio, hacer commits, crear ramas, fusionar y trabajar con repositorios remotos.

## 31.2. Instalación de Git

En la mayoría de distribuciones, Git está disponible en los repositorios oficiales.

Debian/Ubuntu:

“`bash
sudo apt update
sudo apt install git
“`

RHEL/CentOS/Fedora:

“`bash
sudo yum install git # o dnf install git
“`

Verificar la instalación:

“`bash
git –version
“`

## 31.3. Configuración inicial de Git

Antes de empezar, se debe configurar al menos el nombre de usuario y el correo electrónico. Estos datos se asocian a cada commit.

“`bash
git config –global user.name “Tu Nombre”
git config –global user.email “tu@email.com”
“`

Otras configuraciones útiles:

1. Editor por defecto para mensajes de commit:

“`bash
git config –global core.editor nano
“`

2. Colores en la salida:

“`bash
git config –global color.ui auto
“`

3. Ver configuración actual:

“`bash
git config –list
“`

Los archivos de configuración se almacenan en `~/.gitconfig` (global) y `.git/config` (por repositorio).

## 31.4. Conceptos básicos

– **Repositorio**: directorio gestionado por Git, que contiene el historial de cambios.
– **Commit**: instantánea de los archivos en un momento dado, con un mensaje descriptivo.
– **Working directory**: los archivos actuales con los que trabajas.
– **Staging area (índice)**: área intermedia donde se preparan los cambios antes de confirmarlos.
– **Rama (branch)**: línea de desarrollo independiente. La rama principal suele ser `master` o `main`.
– **Fusión (merge)**: combinar cambios de una rama a otra.
– **Remoto (remote)**: copia del repositorio en otro lugar (por ejemplo, GitHub, GitLab o un servidor propio).

El flujo típico es:

1. Modificar archivos en el working directory.
2. Añadirlos al staging area con `git add`.
3. Confirmar los cambios con `git commit`.
4. Repetir.

## 31.5. Crear un repositorio local

### 31.5.1. Inicializar un repositorio nuevo

“`bash
mkdir mi_proyecto
cd mi_proyecto
git init
“`

Esto crea un subdirectorio `.git` con la base de datos del repositorio.

### 31.5.2. Clonar un repositorio existente

“`bash
git clone https://github.com/usuario/repo.git
“`

Esto descarga el repositorio completo y configura el remoto `origin` automáticamente.

## 31.6. Ciclo de trabajo básico

### 31.6.1. Ver el estado

“`bash
git status
“`

Muestra los archivos modificados, añadidos o sin seguimiento.

### 31.6.2. Añadir archivos al staging

– Añadir un archivo específico: `git add archivo.txt`
– Añadir todos los cambios: `git add .` o `git add -A`

### 31.6.3. Confirmar cambios

“`bash
git commit -m “Mensaje descriptivo”
“`

### 31.6.4. Ver el historial

“`bash
git log
git log –oneline –graph –all
“`

### 31.6.5. Ver diferencias

– Entre working directory y staging: `git diff`
– Entre staging y último commit: `git diff –cached`

## 31.7. Ramas (branches)

### 31.7.1. Crear una rama

“`bash
git branch nueva-funcionalidad
“`

### 31.7.2. Cambiar a una rama

“`bash
git checkout nueva-funcionalidad
“`

O bien, crear y cambiar en un solo paso:

“`bash
git checkout -b nueva-funcionalidad
“`

### 31.7.3. Listar ramas

“`bash
git branch
“`

### 31.7.4. Fusionar una rama a la principal

Primero, cambiar a la rama principal (ej. `main` o `master`):

“`bash
git checkout main
“`

Luego fusionar:

“`bash
git merge nueva-funcionalidad
“`

Si no hay conflictos, la fusión es automática. Si hay conflictos, Git marca los archivos en conflicto y hay que resolverlos manualmente.

### 31.7.5. Eliminar una rama

“`bash
git branch -d nueva-funcionalidad
“`

## 31.8. Repositorios remotos

### 31.8.1. Añadir un remoto

Si el repositorio no se clonó de un remoto, se puede añadir:

“`bash
git remote add origin https://github.com/usuario/repo.git
“`

### 31.8.2. Ver remotos configurados

“`bash
git remote -v
“`

### 31.8.3. Enviar cambios (push)

“`bash
git push origin main
“`

### 31.8.4. Obtener cambios (pull)

“`bash
git pull origin main
“`

`git pull` es equivalente a `git fetch` + `git merge`.

### 31.8.5. Actualizar referencias remotas sin fusionar

“`bash
git fetch origin
“`

## 31.9. Deshacer cambios

### 31.9.1. Revertir cambios en el working directory

“`bash
git checkout — archivo.txt
“`

### 31.9.2. Quitar un archivo del staging

“`bash
git reset HEAD archivo.txt
“`

### 31.9.3. Deshacer el último commit (manteniendo cambios)

“`bash
git reset –soft HEAD~1
“`

### 31.9.4. Deshacer el último commit (eliminando cambios)

“`bash
git reset –hard HEAD~1
“`

### 31.9.5. Revertir un commit específico (crea un commit inverso)

“`bash
git revert
“`

## 31.10. Etiquetas (tags)

Las etiquetas se usan para marcar versiones importantes (ej. v1.0).

– Crear una etiqueta ligera: `git tag v1.0`
– Crear una etiqueta anotada: `git tag -a v1.0 -m “Versión 1.0″`
– Listar etiquetas: `git tag`
– Enviar etiquetas al remoto: `git push origin –tags`

## 31.11. Ignorar archivos: `.gitignore`

Muchos archivos no deben versionarse (logs, binarios, configuraciones locales). Para ello se crea un archivo `.gitignore` en la raíz del repositorio. Cada línea es un patrón.

Ejemplo de `.gitignore`:

“`
*.log
*.tmp
node_modules/
.env
“`

Los archivos que coincidan serán ignorados por Git.

## 31.12. Solución de problemas comunes

| Problema | Posible causa | Solución |
|———-|—————|———-|
| “fatal: not a git repository” | Estás fuera de un repositorio | Ejecutar `git init` o entrar en el directorio correcto |
| Commit con autor incorrecto | Configuración global mal establecida | Cambiar con `git config user.name/email` |
| “Updates were rejected” al hacer push | El remoto tiene cambios que no tienes | Ejecutar `git pull` antes de `push` |
| Merge conflict | Dos ramas modificaron la misma línea | Editar el archivo para resolver, luego `git add` y `git commit` |
| No se ignoran archivos | `.gitignore` no existe o patrón incorrecto | Verificar sintaxis y ubicación |
| Perdí cambios con `reset –hard` | Se usó mal | No hay recuperación directa (salvo reflog) |

## 31.13. Ejercicios prácticos

1. **Inicializar y primer commit**: Crea un directorio `proyecto`. Inicializa Git. Crea un archivo `README.md` con algo de texto. Añádelo y haz commit con mensaje “Commit inicial”.

2. **Ciclo de cambios**: Modifica `README.md`, agrega un archivo `script.sh`. Usa `git status`, `git diff`, luego añade y commitea. Revisa `git log`.

3. **Ramas**: Crea una rama `desarrollo`. En esa rama, modifica un archivo. Haz commit. Vuelve a `main` y fusiona. Elimina la rama.

4. **Remoto (simulado)**: Crea un repositorio “remoto” local con `git init –bare /tmp/repo_remoto.git`. Luego, añade ese remoto a tu repositorio local y haz `push`. Clona el repositorio remoto en otra carpeta, modifica algo y haz `push`. Luego en el original haz `pull`.

5. **Etiquetas y .gitignore**: Crea una etiqueta `v1.0`. Añade un `.gitignore` para excluir `*.tmp`. Crea un archivo `prueba.tmp` y verifica que no aparece en `git status`.

6. **Deshacer cambios**: Haz un commit con un cambio incorrecto. Usa `git revert` para deshacerlo. Luego haz otro commit y usa `git reset –soft` para deshacerlo manteniendo los cambios en staging.

## 31.14. Resumen y consejos para LFCS

– Los comandos esenciales son: `init`, `clone`, `add`, `commit`, `status`, `log`, `branch`, `checkout`, `merge`, `push`, `pull`.
– Entiende el flujo de staging: `add` prepara, `commit` confirma.
– Las ramas permiten trabajo paralelo; fusionar es una habilidad clave.
– Los remotos requieren configuración y autenticación (HTTPS o SSH).
– Practica resolver conflictos; es una situación común.
– En el examen, puede pedirse crear un repositorio, hacer commits, crear una rama, fusionar, o clonar un repositorio remoto. Practica estos flujos.

—

Con Git has agregado una herramienta imprescindible para el control de versiones. En el próximo capítulo, el último de esta serie, configuraremos **redes IPv4 e IPv6 y resolución de nombres de host**, cerrando el ciclo de administración de sistemas.