De principiante a experto en GitHub: Una guía completa

Si quieres ganar dinero con GitHub, el camino más directo no es complicado: bajo la premisa del permiso de licencia, encuentra proyectos open-source valiosos, convierte el despliegue, la documentación en chino y el servicio postventa en un servicio, y vende la entrega en plataformas como Xianyu.

Sin embargo, lo que realmente genera dinero es la capacidad de filtrar información y la capacidad de implementación. Si quieres dedicarte a la IA, hacer la transición a FDE (Ingeniero de Desarrollo Full-stack), o convertirte en un OPC (Empresa de Una Sola Persona), el código, la documentación, las versiones y la colaboración terminarán aterrizando en GitHub.

Incluso si te dedicas a la creación y los medios propios, hay una gran cantidad de herramientas de selección de temas, proyectos de automatización y procesos de producción de contenido en GitHub. Una vez que los archivos aumentan y la IA hace cambios, sin Git para gestionar las versiones, las cosas se saldrán de control rápidamente. Por lo tanto, los programadores necesitan aprenderlo, y también los gestores de proyectos y los creadores de contenido; determina si puedes convertir una inspiración en un proyecto manejable, reutilizable y entregable.

He pasado más de medio mes puliendo este artículo, practicando Git, GitHub, Commits, ramas, PRs y errores comunes desde 0 hasta 1. Las transmisiones en vivo futuras también seguirán este mismo proceso. Antes de la transmisión oficial, estoy abriendo este tutorial primero. Puedes marcarlo como favorito o seguirlo por completo.

1. Git y GitHub: ¿Quién Gestiona Qué?

Git es una herramienta de gestión de versiones instalada en tu computadora. Cuando estás desconectado, aún puedes hacer commit, ver el historial, crear ramas y fusionar. GitHub es una plataforma de repositorio remoto y colaboración; recibe los commits enviados por Git y proporciona Issues, Pull Requests, Actions, revisiones de código y gestión de permisos.

Lo más fácil de confundir en Git es que la misma modificación puede existir en cuatro ubicaciones diferentes. La infografía a continuación desglosa el espacio de trabajo, el área de preparación, el repositorio local y el repositorio remoto en cuatro capas.

Presionar guardar solo escribe el contenido en el disco duro. git add se encarga de seleccionar, git commit deja una versión localmente, y git push envía estos commits a GitHub.

Por lo tanto, antes de hacer commit, revisa el diff, ejecútalo o pruébalo; después de enviar exitosamente, vuelve a la página web para verificar dos veces. De esta manera, si ocurre un problema, puedes saber inmediatamente en qué capa se detuvo.

2. Antes de Empezar: Prepara Solo Cuatro Cosas

Necesitas Git, una cuenta de GitHub, un editor y un proyecto de práctica. VS Code es suficiente para el editor, y el proyecto puede ser una página web o un documento Markdown.

Primero, confirma Git en la terminal:

1git --version

Este ejercicio usa macOS y Git 2.49.0. Los usuarios de Windows pueden usar Git Bash o la terminal integrada de VS Code; los comandos de Git a continuación son los mismos.

A continuación, configura el autor del commit:

1git config --global user.name "Tu Nombre"
2git config --global user.email "Tu Correo Electrónico"

Esta es la información del autor que se escribe en el registro del commit; no es responsable de iniciar sesión en GitHub. Si solo quieres configurarlo para el proyecto de práctica actual, reemplaza --global con --local.

El inicio de sesión en GitHub es un asunto aparte. La línea de comandos comúnmente usa tres métodos:

• GitHub CLI, autorizando a través del navegador con gh auth login;
• HTTPS, usando un Token de Acceso Personal o un gestor de credenciales;
• SSH, agregando una clave pública a GitHub y autenticando mediante clave más tarde.

Los principiantes pueden elegir GitHub CLI o HTTPS. Al usar HTTPS, si la terminal solicita una Contraseña, ingresa el Token; las contraseñas de cuenta ordinarias ya no son aplicables. No escribas el Token en comandos, URL remotas, READMEs, chats o capturas de pantalla.

3. No te Apresures a Hacer init: Confirma Dónde Está Realmente la Terminal

Este ejercicio comienza con una página web simple. Se puede abrir en un navegador pero aún no tiene historial de Git.

Hay tres archivos en el proyecto:

1index.html
2style.css
3.gitignore

En VS Code, selecciona "Abrir carpeta", no hagas clic solo en un archivo HTML. Luego ejecuta en la terminal integrada:

1pwd
2ls

pwd muestra el directorio actual, y ls lista los archivos. Continúa solo después de ver index.html y style.css.

Esta verificación parece tonta, pero previene el tipo de accidente más problemático: alguien ejecutando git init en el Escritorio, Documentos, o incluso en el directorio de inicio del usuario, y luego git add . poniendo miles de archivos irrelevantes en el área de preparación. Git no está roto; el directorio estaba mal.

4. ¿Qué Hace git init?

Ahora inicializa el repositorio:

1git init -b main
2git status --short

git init -b main crea un directorio .git en la carpeta actual y nombra la rama inicial main. .git es un directorio oculto donde se almacena información como commits, ramas, áreas de preparación y direcciones remotas. Los archivos del proyecto permanecen en su lugar; Git comienza a observarlos a partir de este momento.

El ?? en la captura de pantalla indica archivos no rastreados. Los archivos existen, pero Git aún no ha decidido si registrarlos.

Para confirmar el directorio raíz del repositorio, puedes ejecutar:

1git rev-parse --show-toplevel

La salida debe ser la carpeta del proyecto actual. Si dice fatal: not a git repository, verifica el directorio primero, luego mira si se ejecutó git init.

5. El Primer Commit: Mantén un Punto de Partida Confiable

El proyecto aún no se ha modificado, ¿por qué hacer commit primero? Porque todos los cambios posteriores necesitan un punto de partida comparable. Primero, abre la página web en un navegador para confirmar que el título, las tarjetas y el área de registro se muestran; reduce la ventana para ver si hay desplazamiento horizontal en el ancho móvil.

Luego mira .gitignore. El contenido utilizado esta vez es:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore se usa para bloquear claves, registros, dependencias y artefactos de compilación. Funciona principalmente en archivos que aún no están rastreados. Si una clave ya se ha commiteado y luego la agregas a .gitignore, ese historial aún existe; el manejo real también incluye revocar o rotar la clave.

Comienza a seleccionar archivos para el primer commit:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

La A en el estado significa Added (Agregado), indicando que el archivo ha entrado en el área de preparación. git diff --cached --stat te dirá cuántos archivos estás preparando para commitear y aproximadamente cuántas líneas se cambiaron. Para ver el contenido específico, ejecuta:

1git diff --cached

Haz commit después de la confirmación:

1git commit -m "chore: Inicializar página de reclutamiento AI del campus"
2git log --oneline
3git status

Un Commit se puede entender como una instantánea del proyecto con autor, hora, descripción y commit padre. ffdf4ff es la versión corta de este hash de commit; usarlo en el repositorio actual puede localizar la versión con precisión.

feat, fix, docs, style, chore son tipos de commit comunes, no una sintaxis obligatoria de Git. Más importante que el prefijo es la descripción en chino (o inglés) que le sigue: qué se hizo, qué objeto se modificó y por qué.

6. El Segundo Commit: Trata las Modificaciones de IA como Borradores para Revisar

A continuación, agrega un botón "Ver método de registro" a la página. Al usar herramientas de programación de IA, escribo los límites en el prompt:

1Solo modifica index.html, agrega un enlace "Ver método de registro" debajo del texto de introducción,
2que enlace a #apply dentro de la página. No modifiques style.css, no ejecutes commits de Git.
3Dime qué archivo se modificó cuando termines.

La modificación manual también es simple:

1<a class="cta" href="#apply">Ver método de registro</a>

La IA dice que está listo, pero no hagas commit todavía. Ejecuta:

1git status --short
2git diff -- index.html
3git diff --check

git diff muestra los cambios en el espacio de trabajo que aún no se han preparado. El + verde es una línea agregada, el - rojo es una línea eliminada. git diff --check no tiene salida, lo que indica que no se encontraron problemas de formato obvios como espacios finales; no verificará si el botón es clickeable por ti.

Vuelve al navegador y actualiza, haz clic en el botón, luego reduce la ventana. La página debe desplazarse al área de registro, y el botón y las tarjetas deben verse normales en pantallas estrechas.

Haz commit solo después de que la prueba pase:

1git add index.html
2git diff --cached
3git commit -m "feat: Agregar entrada de registro para ver rápidamente los métodos de solicitud"
4git log --oneline -2

En este punto, hay dos versiones claras en el repositorio: la página de inicio y el botón de registro. Si el botón tiene problemas más tarde, puedes encontrar directamente qué commit lo agregó.

Por cierto, distingue los dos diffs:

1git diff             # Diferencia entre el espacio de trabajo y el área de preparación
2git diff --cached    # Diferencia entre el área de preparación y el commit más reciente

Si git diff no tiene salida, el archivo podría no estar guardado, o podría ya estar preparado o commiteado. Verificar git status, git diff --cached y git log en secuencia es más confiable que escribir repetidamente git add ..

7. Ramas: Deja un Espacio de Prueba para Cambios Inciertos

El botón solo agrega una línea, por lo que el riesgo es pequeño. Cambiar todo el tema de púrpura a naranja podría verse bien o podría verse de mal gusto; este tipo de modificación es adecuada para una rama.

1git switch -c experiment/warm-theme
2git branch --show-current

Una rama es conceptualmente un nombre que apunta a un cierto commit. Cuando se crea una nueva rama por primera vez, apunta al mismo commit que main, por lo que los archivos son exactamente iguales. Solo cuando la rama experimental genera nuevos commits, las dos líneas divergen.

En el diagrama, el main azul todavía apunta al segundo commit, mientras que el experiment naranja ya apunta al tercer commit. El proyecto no duplicó dos conjuntos de archivos; solo cambiaron los punteros para los dos nombres de rama.

Modifica las variables de color en style.css, actualiza la página para confirmar, y luego haz commit:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Probar tema cálido en la rama experimental"
5git log --oneline --graph --decorate --all

HEAD indica dónde estás parado actualmente. En la captura de pantalla, HEAD apunta a experiment/warm-theme, mientras que main permanece en el commit del botón.

Decide mantener el tema cálido, vuelve a main y fusiona:

1git switch main
2git merge experiment/warm-theme

Aquí ocurre un Fast-forward porque main no tuvo nuevos commits durante el experimento. Git mueve directamente el puntero de main hacia adelante al commit del tema cálido; los cambios se han fusionado con éxito.

Las ramas fusionadas se pueden eliminar de forma segura:

1git branch -d experiment/warm-theme

La -d en minúscula verifica si la rama se ha fusionado. La -D en mayúscula forzará la eliminación, y los commits en la rama que no se han fusionado podrían perder sus referencias; no lo uses como un comando de limpieza diario.

8. Los Conflictos No Son Misteriosos; Git Simplemente No Se Atreve a Elegir por Ti

Para verificar conflictos, dupliqué el repositorio. main cambió el título principal a "Deja que la creatividad del campus sea vista por más personas", y la rama feature cambió la misma línea a "Convierte una idea en un trabajo realmente utilizable". Git se detuvo durante la fusión:

Los marcadores de conflicto se dividen en tres partes:

1<<<<<<< HEAD
2Contenido de la rama actual
3=======
4Contenido de la rama a fusionar
5>>>>>>> feature/rewrite-heading

El método de manejo es editar el archivo, dejar el texto final deseado, eliminar los tres conjuntos de marcadores, probarlo, y luego ejecutar:

1git add index.html
2git commit

Si no quieres manejarlo en ese momento, puedes abortar la fusión:

1git merge --abort

Un conflicto significa que dos personas o dos Agentes dieron respuestas diferentes para la misma ubicación, y Git no puede elegir por sí mismo.

9. Enviar el Repositorio Local a GitHub

El proyecto ya tiene un historial local; ahora ve a GitHub a crear un repositorio. Haz clic en el + en la esquina superior derecha, selecciona "New repository" y completa el nombre del repositorio, por ejemplo:

1campus-ai-demo

Para la primera práctica, se recomienda configurarlo como Privado. Dado que el local ya tiene un README, .gitignore e historial de commits, mantén el nuevo repositorio de GitHub en blanco; no inicialices README, licencia o .gitignore en el lado web. De lo contrario, el local y el remoto tendrán cada uno un fragmento de historial inicial, y el primer push requerirá manejar la relación entre los dos lados primero. La documentación oficial de GitHub "Adding locally hosted code" también lo recuerda explícitamente.

Copia la dirección HTTPS:

1https://github.com/TuUsuario/campus-ai-demo.git

Regresa a la terminal del proyecto:

1git remote add origin https://github.com/TuUsuario/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin es un alias para la dirección remota; puede funcionar con otros nombres, pero la comunidad tiene el hábito de llamar origin al remoto principal. -u establecerá una relación de seguimiento entre el main local y origin/main; las operaciones posteriores generalmente solo ejecutan git push.

El diagrama de terminal a continuación usó un repositorio local vacío para ejecutar push y clone, por lo que no cambió la cuenta de GitHub existente. Al cambiar a GitHub, solo reemplaza la URL de origin; la lógica para que Git pase commits y establezca relaciones de seguimiento es la misma.

Después de que el push real se complete, vuelve a la página web de GitHub y actualiza para confirmar que los archivos, README, rama predeterminada e historial de commits son todos visibles. El mensaje de éxito en la terminal es una capa de evidencia, y la verificación web es otra.

10. Leyendo un Repositorio de GitHub por Primera Vez: Cómo Leer Estas Cosas en la Página

A continuación se muestra la página real del repositorio de documentación oficial de GitHub, capturada el 15 de agosto de 2026.

Al abrir un repositorio, mira estas ubicaciones primero:

• Code: Archivos, directorios, ramas y commits;
• Issues: Errores, requisitos, tareas y discusiones;
• Pull requests: Cambios que esperan revisión o fusión;
• Actions: Pruebas automatizadas, compilación e implementación;
• Security: Políticas de seguridad y funciones relacionadas con vulnerabilidades;
• Insights: Contribuciones, tráfico y actividad del repositorio;
• README: Introducción del proyecto y entrada de uso;
• LICENSE: Cómo se permite usar, modificar y distribuir.

Al leer un proyecto desconocido, no mires primero las Estrellas. Responde primero cinco preguntas: ¿Qué problema resuelve, cómo se ejecuta, de qué depende, se mantiene recientemente y qué me permite hacer la licencia? Las Estrellas reflejan atención; no verifican seguridad, compatibilidad o autorización por ti.

11. clone, fetch, pull, push: No Confundas las Cuatro Direcciones

Llevar un repositorio remoto a tu computadora por primera vez:

1git clone https://github.com/OWNER/REPO.git

Clone trae archivos, historial de commits y configuraciones remotas, generalmente nombrando automáticamente el remoto origin. Descargar un ZIP solo da una instantánea de los archivos en ese momento, sin historial completo, y no establecerá una relación remota.

Las tres acciones comúnmente utilizadas después son:

1git fetch origin   # Descarga información remota, no cambia los archivos de trabajo actuales
2git pull           # fetch y luego integra en la rama actual
3git push           # Envía los commits locales al remoto

Para ver qué sucedió remotamente primero, puedes:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Cuando confirmes que no hay divergencia localmente y solo quieras aceptar actualizaciones fast-forward:

1git pull --ff-only

pull hará fetch primero, y luego realizará merge o rebase según la configuración. Los equipos deben acordar el método de integración antes de la primera colaboración, y no confíes en force push para suavizar los problemas cuando ocurra divergencia.

12. Del Repositorio Personal a la Colaboración en GitHub

Un Pull Request es una propuesta de fusión y donde ocurre la colaboración. Las discusiones, revisiones de código y verificaciones automatizadas giran en torno al mismo conjunto de cambios, y se fusiona en main solo después de la confirmación.

Suponiendo que el Issue es "Agregar descripción de la hora del evento", las operaciones locales se pueden hacer así:

1git switch -c feat/event-time
2# Modificar y probar la página
3git add index.html
4git commit -m "feat: Agregar descripción de la hora del evento"
5git push -u origin feat/event-time

Después de hacer push, GitHub generalmente solicita crear un Pull Request. Un PR es una propuesta de fusión que muestra descripciones, commits, diferencias de archivos, comentarios, revisiones y verificaciones automatizadas. No entrará automáticamente en main solo porque se creó.

Un PR que la gente esté dispuesta a revisar debe explicar al menos tres cosas: qué se cambió, por qué se cambió y cómo verificarlo. Cuanto más enfocados sean los cambios, más fácil será para los revisores detectar problemas.

En el mismo equipo, si tienes acceso de escritura al repositorio, puedes enviar un PR directamente desde una rama. Al contribuir a un proyecto open-source desconocido, la práctica común es hacerle Fork a tu propia cuenta primero, y luego clonar tu propio Fork:

1git clone https://github.com/TuUsuario/NombreDelProyecto.git
2cd NombreDelProyecto
3git remote add upstream https://github.com/AutorOriginal/NombreDelProyecto.git
4git remote -v

Aquí generalmente hay dos remotos:

1origin    Tu propio Fork
2upstream  El repositorio del autor original

Sincroniza el proyecto original:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Luego completa las modificaciones en una nueva rama, haz push a tu propio Fork, y luego envía un PR a upstream. Fork, clone y branch resuelven tres cosas diferentes: Fork es un conjunto de espacio de repositorio en GitHub, clone lleva el repositorio a local, y branch es una línea de desarrollo dentro de un repositorio.

13. README y LICENSE Determinan si Otros se Atreven a Usarlo

Un README debe responder al menos estas preguntas:

1. ¿Qué es el proyecto;
2. ¿Qué problema resuelve;
3. Cómo instalarlo o ejecutarlo;
4. ¿Hasta qué punto está completado actualmente;
5. ¿Dónde están los archivos principales;
6. Quiénes son los autores, materiales y fuentes de citación.

Si el código puede ejecutarse pero el README es vago, es posible que no puedas retomarlo tú mismo tres meses después. Un README mínimo no tiene que ser bonito; solo escribe claramente el proyecto, el método de ejecución y el estado.

Los repositorios públicos tampoco equivalen automáticamente a obtener una licencia open-source. La explicación oficial de la licencia de GitHub establece claramente: cuando no hay licencia, las reglas de derechos de autor predeterminadas aún se aplican, y el autor conserva los derechos de copiar, distribuir y crear trabajos derivados. Público significa que otros pueden verlo y hacerle Fork según los términos de servicio de GitHub; para tomar el código en tu propio proyecto público o comercial, también necesitas mirar la LICENCIA en el repositorio.

MIT, Apache-2.0, GPL, etc., tienen diferentes obligaciones. Al encontrarse con uso comercial, redistribución o licencias mixtas, lee el archivo completo y consulta a un profesional si es necesario; no le preguntes solo a una IA "¿Puedo usarlo con fines comerciales?"

14. Después de Cometer un Error: Determina en Qué Capa Está el Cambio

El arrepentimiento debe elegirse según el estado.

Preparaste el archivo incorrecto pero quieres mantener el contenido del archivo:

1git restore --staged nombre_del_archivo

El mensaje del commit más reciente se escribió incorrectamente y aún no se ha enviado:

1git commit --amend -m "Nuevo mensaje de commit"

Un commit en una rama compartida necesita ser revertido:

1git revert hash_del_commit

revert producirá un nuevo commit inverso, y el historial antiguo permanece visible, lo que es adecuado para ramas que ya se han enviado y son utilizadas por varias personas.

git restore nombre_del_archivo descartará las modificaciones que no se han commiteado; git reset --hard hará que los commits, el área de preparación y el espacio de trabajo vuelvan a una posición especificada; git push --force puede sobrescribir los commits remotos. Estos tres tipos de operaciones requieren confirmación del objetivo y copia de seguridad antes de la ejecución; no los trates como botones de reparación general en la etapa de nivel cero.

15. Los Ocho Errores Más Comunes: Verifica en Este Orden

1. fatal: not a git repository

1pwd
2ls
3git status

Generalmente, el directorio es incorrecto, o el proyecto actual aún no ha sido git init.

2. Author identity unknown

1git config --local user.name "Tu Nombre"
2git config --local user.email "Tu Correo Electrónico"

3. nothing to commit

Verifica si el archivo está guardado, si modificaste otra copia y si los cambios ya se han commiteado:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin DirecciónCorrectaDeGitHub

5. src refspec main does not match any

El repositorio podría no tener un commit todavía, o la rama actual no se llama main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Verifica la URL remota, la propiedad del repositorio, los permisos de la cuenta y el método de autenticación. No envíes el Token a otros para solucionar problemas.

7. rejected non-fast-forward

Hay commits remotos que no están locales. Primero haz fetch y ve las diferencias; no hagas force push directamente:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Ejecuta git status para encontrar archivos UU, determina manualmente el contenido final, prueba, luego add y commit; si no lo manejas por ahora, git merge --abort.

Cuando un estudiante o colega solo dice "Git está roto", pídeles que proporcionen estas cinco salidas:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Luego agrega el sistema operativo, el comando completo que se acaba de ejecutar y el mensaje de error completo. La mayoría de los problemas caerán rápidamente en una de las capas: directorio, estado, identidad, dirección remota o permisos.

16. En la Era de la IA, Git es Más Como un Sistema de Aceptación

La IA puede escribir comandos por ti, pero no puede saber automáticamente qué modificaciones cumplen con las intenciones del negocio. Si un prompt cambia 20 archivos y no revisas el diff, no ejecutas el proyecto y no verificas las claves, Git solo registrará fielmente este desastre.

Una forma más estable es reducir la tarea y poner al humano en la posición de aceptación. Después de que el alcance, las diferencias, las pruebas y las verificaciones de claves pasen, el humano decide si esas modificaciones pueden convertirse en un commit.

Al dejar que la IA opere Git, también establece límites:

1Por favor, revisa primero git status y git diff, y solo resume los cambios actuales.
2No descartes ningún contenido sin commit, no ejecutes reset --hard, clean o force push.
3Proporciona los resultados de verificación después de completar las modificaciones, no hagas commit ni push automáticamente.

Ya no es tan importante si puedes memorizar comandos. Necesitas poder leer el estado, saber qué movió la IA, juzgar si la verificación es suficiente y detenerte cuando aparezcan operaciones peligrosas.

17. Ejecuta Todo el Proceso de Nuevo

1# 1. Confirmar ubicación
2pwd
3ls
4
5# 2. Inicializar
6git init -b main
7git status
8
9# 3. Primer commit
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Inicializar proyecto"
13
14# 4. Modificar, revisar, probar, commit de nuevo
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Agregar entrada de registro"
20
21# 5. Experimentar con ramas
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Experimentar con tema cálido"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Conectar a GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Verificación final
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

Cuando puedas explicar qué capa cambió cada comando y puedas manejar de forma independiente un directorio incorrecto, un error de staging y un conflicto de fusión, GitHub ya no será solo un sitio web para almacenar código. Ya eres capaz de convertir proyectos personales en repositorios que se pueden revisar, auditar y colaborar.

El siguiente paso no requiere seguir coleccionando comandos. Encuentra un proyecto pequeño real y hazlo durante 7 días consecutivos: completa solo una pequeña modificación cada día, revisa el diff, prueba, haz commit y luego haz push a GitHub. El historial de commits convertirá lentamente este conjunto de cosas en tu hábito de trabajo.

Soy Miles, un experto en algoritmos de IA que pasó de una gran empresa a FDE. He trabajado en I+D de algoritmos, despliegue de optimización y capacitación corporativa. Sígueme @miles_mazy Crecer juntos, ganar dinero juntos.