Git vs GitHub: ¿Qué es el control de versiones y cómo funciona?

¿Alguna vez te ha confundido cómo funcionan Git y GitHub? No se preocupe, no está solo. Git y GitHub pueden ser complicados a veces, pero al final de esta publicación tendrás una buena comprensión de los dos.

Al principio, puede resultar tentador creer que Git y GitHub son lo mismo. Pero en realidad no lo son. De hecho, ¡es posible usar Git sin GitHub! Y, en última instancia, los dos existen para diferentes propósitos.

Esta publicación comenzará analizando detenidamente los propósitos de Git y GitHub. Luego, aprenderemos sobre las principales diferencias entre estas dos tecnologías vitales.

Sin más preámbulos, comencemos con Git.

¿Qué es Git?

Git es un sistema de control de versiones distribuido (DVCS) que se utiliza para guardar diferentes versiones de un archivo (o conjunto de archivos) para que cualquier versión se pueda recuperar a voluntad.

Git también facilita la grabación y comparación de diferentes versiones de archivos. Esto significa que los detalles sobre qué cambió, quién cambió qué o quién inició un problema se pueden revisar en cualquier momento.

Pero si Git es un sistema de control de versiones distribuido, ¿qué significan exactamente esos términos?

¿Qué significa "distribuido"?

El término "distribuido" significa que cada vez que le indica a Git que comparta el directorio de un proyecto, Git no solo comparte la última versión del archivo. En cambio, distribuye todas las versiones que ha grabado para ese proyecto.

Este sistema "distribuido" contrasta fuertemente con otros sistemas de control de versiones. Solo comparten cualquier versión individual que un usuario haya extraído explícitamente de la base de datos central / local.

Bien, entonces "distribuido" significa distribuir todas , no solo unas pocas, las versiones de los archivos de un proyecto que Git ha grabado. Pero, ¿qué es exactamente un sistema de control de versiones?

¿Qué es un sistema de control de versiones?

Un sistema de control de versiones (VCS) se refiere al método utilizado para guardar las versiones de un archivo para referencia futura.

Intuitivamente, muchas personas ya el control de versiones de sus proyectos de cambio de nombre de las diferentes versiones de un mismo archivo de varias maneras como blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, y así sucesivamente. Pero este enfoque es propenso a errores e ineficaz para proyectos en equipo.

Además, rastrear qué cambió, quién lo cambió y por qué se cambió es una tarea tediosa con este enfoque tradicional. Esto ilumina la importancia de un sistema de control de versiones confiable y colaborativo como Git.

Sin embargo, para obtener lo mejor de Git, es esencial comprender cómo Git maneja sus archivos.

Estados de archivos en Git

En Git, hay tres estados (condiciones) principales en los que un archivo puede estar: estado modificado , estado por etapas o estado comprometido .

Estado modificado

Un archivo en el estado modificado es un archivo revisado, pero no confirmado (no registrado).

En otras palabras, los archivos en el estado modificado son archivos que ha modificado pero que no ha indicado explícitamente a Git que los supervise.

Estado por etapas

Los archivos en el estado por etapas son archivos modificados que se han seleccionado, en su estado actual (versión), y se están preparando para guardar (confirmar) en el .gitrepositorio durante la siguiente instantánea de confirmación.

Una vez que un archivo se prepara, implica que ha autorizado explícitamente a Git a monitorear la versión de ese archivo.

Estado comprometido

Los archivos en el estado comprometido son archivos almacenados correctamente en el .gitrepositorio.

Por lo tanto, un archivo confirmado es un archivo en el que ha registrado su versión provisional en el directorio (carpeta) de Git.

Nota: El estado de un archivo determina la ubicación donde lo colocará Git.

Ubicaciones de archivos

Hay tres lugares clave en los que las versiones de un archivo pueden residir mientras se controla la versión con Git: el directorio de trabajo , el área de prueba o el directorio de Git .

Directorio de trabajo

El directorio de trabajo es una carpeta local para los archivos de un proyecto. Esto significa que cualquier carpeta creada en cualquier lugar de un sistema es un directorio de trabajo.

Nota:

  • Los archivos en el estado modificado residen en el directorio de trabajo.
  • El directorio de trabajo es diferente del .gitdirectorio. Es decir, creas un directorio de trabajo mientras Git crea un .gitdirectorio.
  • Consulte este artículo comparativo para conocer más diferencias entre los dos repositorios.

Área de ensayo

El área de preparación, técnicamente llamada "índice" en el lenguaje de Git, es un archivo, generalmente ubicado en el .gitdirectorio, que almacena información sobre los archivos siguientes que se enviarán al .gitdirectorio.

Nota:

  • Los archivos en el estado de preparación residen en el área de preparación.

Directorio de Git

El .gitdirectorio es la carpeta (también llamada "repositorio") que Git crea dentro del directorio de trabajo que le ha indicado que realice un seguimiento.

Además, la .gitcarpeta es donde Git almacena las bases de datos de objetos y los metadatos de los archivos que le ha indicado que supervise.

Nota:

  • El .gitdirectorio es la vida de Git: es el elemento que se copia cuando clona un repositorio desde otra computadora (o desde una plataforma en línea como GitHub).
  • Los archivos en el estado comprometido residen en el directorio Git.

El flujo de trabajo básico de Git

Trabajar con el sistema de control de versiones de Git se parece a esto:

Diagrama de flujo de trabajo básico de Git
  1. Modifique archivos en el directorio de trabajo.

    Tenga en cuenta que cualquier archivo que modifique se convierte en un archivo en estado modificado .

  2. Organice de forma selectiva los archivos que desea enviar al .gitdirectorio.

    Tenga en cuenta que cualquier archivo que prepare (agregue) en el área de preparación se convierte en un archivo en estado de preparación .

    Además, tenga en cuenta que los archivos preparados todavía no están en la .gitbase de datos.

    La preparación significa que la información sobre el archivo preparado se incluye en un archivo (llamado "índice") en el .gitrepositorio.

  3. Confirme los archivos que ha almacenado en el .gitdirectorio. Es decir, almacene permanentemente una instantánea de los archivos en etapas en la .gitbase de datos.

    Tenga en cuenta que cualquier versión de archivo que confirme en el .gitdirectorio se convierte en un archivo en estado comprometido .

La esencia hasta ahora

Lo largo y corto de toda la discusión hasta ahora es que Git es un brillante sistema de control de versiones para control de versiones, administración y distribución de archivos competentes. Consulte esta sencilla guía para aprender a usar Git de manera eficiente.

Pero, espere un segundo, si Git ayuda a administrar y distribuir de manera efectiva diferentes versiones del archivo de un proyecto, ¿cuál es el propósito de GitHub?

GitHub desmitificado

GitHub es una plataforma basada en web donde los usuarios pueden alojar repositorios de Git. Le ayuda a facilitar el uso compartido y la colaboración en proyectos con cualquier persona en cualquier momento.

GitHub también fomenta una participación más amplia en proyectos de código abierto al proporcionar una forma segura de editar archivos en el repositorio de otro usuario.

Para alojar (o compartir) un repositorio de Git en GitHub, siga los pasos a continuación:

Paso 1: Regístrese para obtener una cuenta de GitHub

El primer paso para comenzar a alojar en GitHub es crear una cuenta personal. Visite la página de registro oficial para registrarse.

Paso 2: Crea un repositorio remoto en GitHub

Después de registrarse para obtener una cuenta, cree una casa (un repositorio) en GitHub para el repositorio de Git que desea compartir.

Paso 3: conecta el directorio Git del proyecto al repositorio remoto

Una vez que haya creado un repositorio remoto para su proyecto, vincule el .gitdirectorio del proyecto, ubicado localmente en su sistema, con el repositorio remoto en GitHub.

Para conectarse al repositorio remoto, vaya al directorio raíz del proyecto que desea compartir a través de su terminal local y ejecute:

git remote add origin //github.com/yourusername/yourreponame.git

Nota:

  • Reemplaza yourusernameel código anterior con tu nombre de usuario de GitHub.

    Asimismo, reemplácelo yourreponamecon el nombre del repositorio remoto al que desea conectarse.

  • El comando anterior implica que git debe agregar la URL especificada al proyecto local como una referencia remota con la que el .gitdirectorio local puede interactuar.
  • La originopción en el comando anterior es el nombre predeterminado (un nombre corto) que Git le da al servidor que aloja su repositorio remoto.

    Es decir, en lugar de la URL del servidor, Git usa el nombre corto origin.

  • No es obligatorio seguir con el nombre predeterminado del servidor. Si prefiere otro nombre en lugar de origin, simplemente sustituya el originnombre en el git remote addcomando anterior con el nombre que prefiera.
  • Recuerde siempre que el nombre corto de un servidor (por ejemplo,   origin) no es nada especial. Solo existe, localmente, para ayudarlo a hacer referencia fácilmente a la URL del servidor. Así que siéntase en cambiarlo por un nombre corto al que pueda hacer referencia fácilmente.
  • Para cambiar el nombre de cualquier URL remota existente, use el git remote renamecomando así:
git remote rename theCurrentURLName yourNewURLName
  • Siempre que clona (descarga) cualquier repositorio remoto, Git nombra automáticamente la URL de ese repositorio origin. Sin embargo, puede especificar un nombre diferente con el git clone -o yourPreferredNamecomando.
  • Para ver la URL exacta almacenada para apodos como origin, ejecute el git remote -vcomando.

Paso 4: confirma la conexión

Una vez que haya conectado su directorio Git al repositorio remoto, verifique si la conexión fue exitosa ejecutándose git remote -ven la línea de comando.

Luego, verifique la salida para confirmar que la URL mostrada es la misma que la URL remota a la que desea conectarse.

Nota:

  • Consulte el artículo "Conexión con SSH" si desea conectarse utilizando la URL SSH en lugar de la URL HTTPS.
  • Sin embargo, si no está seguro de la URL remota que debe usar, consulte la sección "¿Qué URL remota debo usar?" artículo.
  • ¿Desea cambiar su URL remota? Cambiar la URL de un control remoto es una guía excelente.

Paso 5: enviar un repositorio de Git local al repositorio remoto

Después de conectar con éxito su directorio local al repositorio remoto, puede comenzar a enviar (cargar) su proyecto local en sentido ascendente.

Siempre que esté listo para compartir su proyecto en otro lugar, en cualquier repositorio remoto, simplemente indique a Git que envíe todas sus confirmaciones, ramas y archivos en su .gitdirectorio local al repositorio remoto.

La sintaxis de código utilizada para cargar (enviar) un directorio Git local a un repositorio remoto es git push -u remoteName branchName.

Es decir, para enviar su .gitdirectorio local , y asumiendo que el nombre corto de la URL remota es "origen", ejecute:

git push -u origin master

Nota:

  • El comando anterior implica que git debe enviar su rama maestra local a la rama maestra remota ubicada en la URL denominada origen .
  • Técnicamente, puede sustituir la originopción con la URL del repositorio remoto. Recuerde, la originopción es solo un apodo de la URL que ha registrado en su .gitdirectorio local .
  • El -uindicador (indicador de referencia de seguimiento / aguas arriba) vincula automáticamente la .gitrama local del directorio con la rama remota. Esto le permite usar git pullsin ningún argumento.

Paso 6: confirma la carga

Por último, vuelva a la página del repositorio de GitHub para confirmar que Git ha enviado correctamente su directorio de Git local al repositorio remoto.

Nota:

  • Es posible que deba actualizar la página del repositorio remoto para que se reflejen los cambios.
  • GitHub también tiene una instalación opcional gratuita para convertir su repositorio remoto en un sitio web funcional. Veamos "cómo" a continuación.

Publique su sitio web con páginas de GitHub

Después de enviar su proyecto a su repositorio remoto, puede publicarlo fácilmente en la web así:

  1. Asegúrese de que el nombre del archivo HTML principal de su proyecto sea index.html.
  2. En la plataforma del sitio web de GitHub, vaya al repositorio del proyecto que desea publicar y haga clic en la pestaña de configuración del repositorio .
  3. Desplácese hacia abajo hasta la sección Páginas de GitHub y cambie la rama Fuente de ninguna a maestra .
  4. Luego, aparecerá una notificación que dice: "Su sitio está publicado en //your-username.github.io/your-github-repo-name/ ".
  5. Ahora puede ver y publicitar su proyecto en la URL especificada.

Esta sección simplemente ha arañado la superficie de la publicación de su proyecto con GitHub. Para obtener más información sobre las páginas de GitHub, consulte esta documentación "Trabajar con páginas de GitHub".

En breve

GitHub es una plataforma en línea para alojar (o compartir) repositorios de Git. Le ayuda a crear una vía para colaborar fácilmente en proyectos con cualquier persona, en cualquier lugar y en cualquier momento.

¿Aún tienes dudas?

¿Todavía estás perplejo por la delgada línea entre Git y GitHub? No se preocupe, lo tengo cubierto. A continuación, se muestran cinco diferencias clave entre Git y GitHub.

Diferencia 1: Git vs.GitHub - Función principal

Git es un sistema de control de versiones distribuido que registra diferentes versiones de un archivo (o conjunto de archivos). Permite a los usuarios acceder, comparar, actualizar y distribuir cualquiera de las versiones grabadas en cualquier momento.

Sin embargo, GitHub es principalmente una plataforma de alojamiento para alojar repositorios de Git en línea. Permite a los usuarios mantener su repositorio remoto privado o abierto para esfuerzos de colaboración.

Diferencia 2: Git vs.GitHub - Plataforma operativa

Los usuarios instalan y operan Git en sus máquinas locales. Esto significa que la mayoría de las operaciones de Git se pueden realizar sin Internet.

Sin embargo, GitHub es un servicio basado en web que opera únicamente en línea. Esto significa que necesita Internet para hacer cualquier cosa en GitHub.

Diferencia 3: Git vs.GitHub - Inventores

Linus Torvalds comenzó el desarrollo de Git en abril de 2005.

Chris Wanstrath, PJ Hyett, Tom Preston-Werner y Scott Chacon fundaron GitHub.com en febrero de 2008.

Diferencia 4: Git vs GitHub - Mantenedores

En julio de 2005, Linus Torvalds entregó el mantenimiento de Git a Junio ​​C. Hamano, quien ha sido el encargado de mantenimiento desde entonces.

Y Microsoft adquirió GitHub en octubre de 2018.

Diferencia 5: Git vs.GitHub - Competidores

Las alternativas populares a Git son Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion e IBM Rational ClearCase.

Los competidores más cercanos de GitHub son GitLab, Bitbucket, SourceForge, Cloud Source Repositories y AWS CodeCommit.

Considerándolo todo

Git y GitHub son dos entidades diferentes que lo ayudan a administrar y alojar archivos. En otras palabras, Git sirve para controlar las versiones de archivos, mientras que GitHub es una plataforma para alojar repositorios de Git.

Recurso útil

  • Cómo usar Git: una guía impresionante con consejos increíbles