Diseño Web - Técnicos

5. Práctica

Se lee en 5 min

Dos ejercicios. El primero se hace solo; el segundo, en parejas. No se entregan para nota, pero son la base de cómo se entregan los tres trabajos del curso.

Por qué en lenguaje C

El objetivo aquí es practicar Git, no programar. Un programa en C de cinco líneas basta para tener algo que modificar, y evita mezclar el aprendizaje de Git con el de HTML.

Para compilar necesitas gcc:

sudo apt install gcc

Ejercicio 1 — Individual

Objetivo: recorrer el ciclo completo, desde crear el repositorio hasta ver tu código publicado en GitHub.

Paso 1. Crea el repositorio en GitHub

Sigue lo visto en Instalación y cuenta:

  • Nombre: practica-git
  • Público
  • Marca Add a README file

Paso 2. Clónalo

cd ~
git clone https://github.com/tu-usuario/practica-git.git
cd practica-git
code .

Paso 3. Escribe el programa

Crea un archivo hola.c:

#include <stdio.h>
 
int main() {
    printf("Hola, me llamo <TU NOMBRE>\n");
    return 0;
}

Compílalo y ejecútalo para comprobar que funciona:

gcc hola.c -o hola
./hola

Paso 4. Primer commit

git status                                  # ¿Qué archivos ve Git?
git add hola.c
git commit -m "Agrega programa que saluda"
git push

No subas el ejecutable

gcc genera un archivo hola (sin extensión) que no debe ir al repositorio: es un binario que se regenera al compilar. Por eso el git add hola.c es específico, en vez de git add ..

La forma correcta de excluirlo permanentemente es crear un archivo .gitignore con una línea que diga hola. Pruébalo y vuelve a ejecutar git status.

Paso 5. Un segundo commit

Modifica el programa para que además imprima tu carrera:

printf("Estudio <TU CARRERA>\n");

Y repite el ciclo, observando el diff:

git diff                                    # ¿Qué líneas cambiaron?
git add hola.c
git commit -m "Agrega la carrera al saludo"
git push

Paso 6. Verifica en GitHub

Entra a github.com/tu-usuario/practica-git y comprueba que:

  • El archivo hola.c está ahí con la última versión.
  • En la pestaña Commits aparecen tus dos commits, con sus mensajes.
  • Al hacer clic en un commit, ves las líneas agregadas en verde.
  • Los commits aparecen a tu nombre (si dicen otro nombre, revisa git config --global --list).

Ejercicio 2 — En parejas

Objetivo: ver cómo se trabaja en grupo y provocar un conflicto a propósito para aprender a resolverlo. Es mejor encontrárselo aquí que el día antes de una entrega.

Paso 1. Preparar

Uno de los dos (llamémosle A) crea un repositorio practica-grupal con README.

A invita a su compañero: en el repositorio, Settings → Collaborators → Add people, con el usuario de GitHub de B. B acepta la invitación que le llega por correo.

Ambos clonan:

git clone https://github.com/usuario-de-A/practica-grupal.git
cd practica-grupal

Paso 2. Trabajo sin conflicto

Cada uno crea su propio archivo:

  • A crea saludo-a.c
  • B crea saludo-b.c

Ambos hacen el ciclo completo:

git add .
git commit -m "Agrega mi saludo"
git push

El segundo en subir va a recibir un rechazo

Git dirá algo como Updates were rejected because the remote contains work that you do not have locally. Es lo esperado: el remoto avanzó. La solución es traer lo nuevo y volver a subir:

git pull
git push

Al terminar, ambos ejecutan git pull y comprueban que tienen los dos archivos. No hubo conflicto, porque cada uno tocó un archivo distinto.

Paso 3. Provocar el conflicto

Ahora, sin hacer pull ni avisarse, los dos editan la misma línea del README.md:

  • A escribe en la primera línea: # Práctica grupal de A y B
  • B escribe en la primera línea: # Repositorio de práctica

A sube primero:

git add README.md
git commit -m "Actualiza el titulo del README"
git push

B intenta subir y falla. Al hacer git pull, aparece el conflicto:

CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Paso 4. Resolver

B abre README.md y encuentra las marcas:

<<<<<<< HEAD
# Práctica grupal de A y B
=======
# Repositorio de práctica
>>>>>>> ...

B conversa con A, decide qué título queda, borra las tres líneas de marcas y guarda. Luego:

git add README.md
git commit -m "Resuelve conflicto en el titulo del README"
git push

A ejecuta git pull y ve el resultado acordado.

Paso 5. Verificar

  • El README.md no contiene ninguna marca <<<<<<<, ======= ni >>>>>>>.
  • En Commits aparecen commits de ambos, cada uno a su nombre.
  • Existe un commit de fusión (merge) en el historial.
  • Ambos tienen exactamente el mismo contenido tras un git pull.

Qué deberías poder hacer después de esto

  • Crear un repositorio y clonarlo sin consultar apuntes.
  • Ejecutar el ciclo pull → add → commit → push de memoria.
  • Interpretar lo que dice git status.
  • Entender por qué te rechazaron un push y cómo solucionarlo.
  • Resolver un conflicto sin entrar en pánico.

Cómo evitar conflictos en los trabajos

El Paso 3 fue un conflicto provocado. En un trabajo real se evitan con dos costumbres: hacer git pull antes de empezar a trabajar y repartirse los archivos para que dos personas no editen lo mismo al mismo tiempo. Cuando eso no alcanza, se usan ramas.

Vista Gráfica

Retroenlaces