Git y GitHub

GIT

Git es un Sistema de Control de Versiones Distribuido (DVCS) utilizado para guardar diferentes versiones de un archivo (o conjunto de archivos) para que cualquier versión sea recuperable cuando lo desee.

Git también facilita el registro y comparación de diferentes versiones de un archivo. Esto significa que los detalles sobre qué cambió, quién cambió qué, o quién ha iniciado una propuesta, se pueden revisar en cualquier momento.

¿Pero si Git es un Sistema de Control de Versiones Distribuido, qué significan exactamente esos términos?

Pues el término “distribuido” significa que cuando le instruyes a Git que comparta el directorio de un proyecto, Git no sólo comparte la última versión del archivo. En cambio, distribuye cada versión que ha registrado para ese proyecto.

Bueno, entonces “distribuido” significa distribuir todas – no solo algunas seleccionadas – versiones de los archivos del proyecto que Git haya registrado. Pero ¿qué es exactamente 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.

De manera intuitiva muchas personas ya utilizan control de versiones en sus proyectos al renombrar las distintas versiones de un mismo archivo de varias formas como blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, etcétera. Pero esta forma de abordarlo es propenso a errores y inefectivo para proyectos grupales.

Además, con esta forma de abordarlo, rastrear qué cambió, quién lo cambió y porqué se cambió, es un esfuerzo tedioso. Esto resalta la importancia de un sistema de control de versiones confiable y colaborativo como Git.

Sin embargo, para obtener lo mejor de Git, es importante entender cómo Git administra tus archivos.

En Git hay tres etapas primarias (condiciones) en las cuales un archivo puede estar: estado modificado, estado preparado, o estado confirmado.

Estado modificado

Un archivo en el estado modificado es un archivo revisado – pero no acometido (sin registrar).

En otras palabras, archivos en el estado modificado son archivos que has modificado pero no le has instruido explícitamente a Git que controle.

Estado preparado

Archivos en la etapa preparado son archivos modificados que han sido seleccionados – en su estado (versión) actual – y están siendo preparados para ser guardados (acometidos) al repositorio .git durante la próxima instantánea de confirmación.

Una vez que el archivo está preparado implica que has explícitamente autorizado a Git que controle la versión de ese archivo.

Estado confirmado

Archivos en el estado confirmado son archivos que se guardaron en el repositorio .git exitosamente.

Por lo tanto un archivo confirmado es un archivo en el cual has registrado su versión preparada en el directorio (carpeta) Git.

Flujo de trabajo básico de Git

1. Modificar archivos en el directorio de trabajo.
   Observe que cualquier archivo que modifiques se convierte en un archivo en el estado modificado.
2. Prepare selectivamente los archivos que quieras confirmar al directorio .git.
   Observe que cualquier archivo que prepares (agregues) a la zona de preparación se convierte en un archivo en el estado preparado.  
   También tenga en cuenta que los archivos preparados todavía no están en la base de datos .git.
   Preparar significa que la información sobre el archivo preparado se incluye en un archivo (llamado “index”) en el repositorio .git.
3. Confirme el/los archivos que has preparado en el directorio .git. Esto es, guardar de manera permanente una instantánea de los archivos preparados en la base de datos .git.
   Observe que cualquier versión del archivo que confirmes al directorio .git se convierte en un archivo en el estado confirmado.

En resumidas cuentas de todo lo discutido hasta el momento es que Git es un sistema de control de versiones genial para versionado, administración y distribución de archivos.

Pero espera un segundo, si Git nos ayuda en la administración y distribución eficaz de distintas versiones de los archivos de un proyecto,  ¿cúal es el propósito de GitHub?

GitHub

GitHub es una plataforma basada en la web donde los usuarios pueden alojar repositorios Git. Facilita compartir y colaborar fácilmente en proyectos con cualquier persona en cualquier momento.

GitHub también fomenta una participación más amplia en proyectos Código Abierto al proporcionar una manera segura de editar archivos en repositorios de otros usuarios.

Para alojar (o compartir) un repositorio Git en GigHub, sigue los siguientes pasos:

Paso 1: Registrar una cuenta de GitHub

Visita la página de registro oficial para registrarse.

Paso 2: Crear un repositorio remoto en GitHub

Después de registrarse, crear un home (un repositorio) en GitHub para el repositorio Git que quieres compartir.

Paso 3: Conectar el directorio Git del proyecto con el repositorio remoto

Una vez que hayas creado un repositorio remoto para tu proyecto, tienes que vincular el directorio .git del proyecto – ubicado localmente en tu sistema – con el repositorio remoto en GitHub.

git remote add origin https://github.com/tuUsuario/tuRepositorio.git

• Reemplaza tuUsuario en el código de arriba con tu nombre de usuario de GitHub.
  También reemplaza tuRepositorio con el nombre del repositorio remoto al que te quieres conectar.
• El comando de arriba implica que git debe agregar al proyecto la URL especificada como una referencia remota con la cual el directorio local .git puede interactuar.
• La opción origin en el comando de arriba es el nombre predeterminado (un nombre corto) que Git le otorga al servidor que aloja tu repositorio remoto.
  Es decir, Git utiliza el nombre corto origin en vez de la URL del servidor.
• No es obligatorio quedarse con el nombre predeterminado del servidor. Si prefieres otro nombre que origin, simplemente sustituya el nombre origin en el comando git remote add de arriba por cualquier nombre que prefieras.
• Siempre recuerda que un nombre corto del servidor (por ejemplo,  origin) no es nada especial! Sólo existe – localmente – para ayudarte a referenciar fácilmente la URL del servidor. Por lo tanto, siéntete libre de cambiarlo a un nombre corto que puedas referenciar fácilmente.
• Para renombrar cualquier URL remota que exista, utilice el comando git remote rename de esta manera:

git remote rename nombreURLactual nuevoNombreURL

• Cada vez que clones (descargues) cualquier repo remota, Git automáticamente le pone nombre origin a la URL de la repo. Sin embargo, le puedes especificar un nombre distinto con el comando git clone -o tuNombrePreferido.
• Para ver la URL exacta guardada para los nombres como origin, ejecuta el comando git remote -v.

Paso 4: Confirmar la conexión

Una vez que hayas conectado tu directorio Git con el repositorio remoto, verifica si la conexión fue exitosa ejecutando el comando git remote -v.

Después verifica la impresión para confirmar que la URL mostrada sea la misma que la URL remota que intentas conectarte.

Paso 5: Subir un repo Git local a un repo remoto

Después de conectar exitosamente tu directorio local con el repositorio remoto puedes comenzar a subir (cargar) tu proyecto local upstream.

Cuando estés listo para compartir tu proyecto en otra parte, en cualquier repo remoto, simplemente le dices a Git que suba todos tus confirmaciones, ramas y archivos en tu directorio .git local al repositorio remoto.

La sintaxis del código utilizado para subir (push) un directorio local Git a un repositorio remoto es git push -u nombreRemoto nombreRama.

Esto es, para subir tu directorio local .git y suponiendo que el nombre corto de la URL remota es “origin”, ejecuta:

git push -u origin master

Paso 6: Confirmar la subida

Por último, vuelve a tu página de repositorio GitHub para confirmar que Git haya subido exitosamente tu directorio Git local al repositorio remoto.

Nota:

• Tal vez tengas que refrescar la página del repositorio remoto para reflejar los cambios.
• GitHub también tiene un servicio gratuito opcional para convertir tu repositorio remoto en una página web funcional. Abajo vamos a ver “cómo” hacerlo.-

Conclusiones

GitHub es una plataforma en línea de alojamiento (o para compartir) repositorios de Git. Nos ayuda crear una avenida para colaborar fácilmente con cualquier persona, en cualquier lugar, en cualquier momento.

Primera diferencia:

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

Sin embargo GitHub principalmente es una plataforma de alojamiento para albergar tus repositorios Git en la web. Esto permite a los usuarios mantener sus repositorios remotos privados o abiertos para esfuerzos colaborativos.

Segunda diferencia:

Los usuarios instalan y ejecutan Git en sus equipos locales. Esto significa que la mayoría de las operaciones de Git se pueden lograr sin una conexión a internet.

Sin embarg GitHub es un servicio basado en la web que opera solamente en línea. Esto significa que necesitas estar conectado para hacer cualquier cosa en GitHub.

Opciones:

Algunas alternativas populares para Git son Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion, y IBM Rational ClearCase.

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

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

Te invitamos a continuar leyendo más de nuestros artículos. ¿Tienes alguna sugerencia o duda respecto a los servicios de consultoría y transformación digital para acelerar a tu organización y alcanzar tus metas? No dudes en contactarnos.

Contenido original – Git vs GitHub – What is Version Control and How Does it Work? de Oluwatobi Sofela