Cuando compilas un proyecto en .NET, el framework genera carpetas que muchos desarrolladores novatos no entienden del todo. Saber qué contienen, cuándo ignorarlas y cómo proteger tu código con Git y GitHub es fundamental para mantener un flujo de trabajo profesional y ordenado desde el primer día.

¿Qué contienen las carpetas bin y obj en un proyecto .NET?

Al compilar con dotnet run, .NET crea automáticamente dos carpetas dentro de tu proyecto que cumplen roles distintos pero complementarios.

La carpeta bin almacena los binarios, es decir, el código compilado listo para ejecutar [0:10]. Dentro encontrarás archivos como InventarioApp.dll. Un archivo DLL (Dynamic Link Library) es un archivo compilado que contiene código ejecutable y puede ser compartido entre múltiples programas [0:18].

La carpeta obj, por su parte, guarda todos los archivos temporales de compilación [0:28]. .NET la usa internamente y nunca deberías modificar su contenido de forma manual.

¿Qué sucede si eliminas bin y obj?

Si borras ambas carpetas y ejecutas dotnet run, .NET las regenera automáticamente [0:44]. Esto significa que no son indispensables dentro de tu repositorio, ya que cualquier persona que clone el proyecto puede reconstruirlas con un solo comando.

¿Cómo configurar un archivo .gitignore para proyectos .NET?

Para que Git nunca rastree las carpetas generadas por la compilación, se utiliza un archivo llamado .gitignore [1:00]. Crearlo es sencillo: dentro de la raíz de tu proyecto, genera un nuevo archivo con el nombre exacto .gitignore [1:12].

Dentro de este archivo se deben incluir varias categorías:

• Archivos de compilación: las carpetas bin y obj, que se regeneran automáticamente.
• Archivos del editor: configuraciones propias de Visual Studio u otro IDE.
• Archivos temporales: como logs o archivos temp.
• Archivos del sistema operativo: que no aportan nada al funcionamiento del proyecto.

¿Cuál es el flujo básico de Git para subir un proyecto?

Una vez configurado el .gitignore, el siguiente paso es inicializar el repositorio local y conectar con GitHub [1:52].

1. git init para inicializar el repositorio.
2. git status para verificar el estado de los archivos.
3. git add . para añadir todos los archivos al staging area.
4. git commit -m "mensaje descriptivo" para crear una instantánea de los cambios.

Recuerda que los mensajes de commit deben ser siempre descriptivos [2:16]. Un buen ejemplo: "Primer push con estructura base de proyecto y configuración de git ignore".

¿Cómo subir tu proyecto .NET a GitHub por primera vez?

Tener el código solo en tu computadora es un riesgo: si tu equipo falla, pierdes todo [2:30]. Subir a GitHub es la solución.

Desde github.com, crea un nuevo repositorio asignándole nombre y descripción [2:42]. Al crearlo, evita agregar README o .gitignore desde GitHub si ya los generaste localmente, así previenes conflictos innecesarios [3:06].

Para conectar y subir:

• git branch -M main selecciona la rama principal.
• git remote add origin <URL> vincula tu repositorio remoto.
• git push -u origin main realiza el primer push [3:40].

¿Qué es el archivo .gitkeep y para qué sirve?

GitHub no sube carpetas vacías al repositorio. Para forzar que una carpeta como models exista, se coloca un archivo llamado .gitkeep dentro de ella [4:14]. Es una convención de la comunidad, no una funcionalidad oficial de Git.

¿Cómo simplificar los push posteriores?

Después del primer git push -u origin main, los siguientes push a la misma rama solo necesitan git push [4:52]. El flag -u establece la rama de seguimiento remoto.

El flujo constante a partir de este punto será [3:56]:

• git add .
• git commit -m "descripción del avance"
• git push

Sin embargo, en entornos profesionales es buena práctica trabajar en ramas paralelas y solicitar revisión de código antes de fusionar con main [5:02].

Si estás comenzando con .NET y Git, dominar este flujo temprano te ahorrará problemas a futuro. Comparte en los comentarios el orden del flujo de Git que practicaste y cuéntanos cómo te fue con tu primer push.