Todo lo que necesitas saber sobre Commit en GitHub

Historia ¿Cómo se desarrollo?

Con Git como el sistema de control de versiones subyacente, GitHub heredó la noción de commit como una parte esencial del flujo de trabajo de desarrollo. Cuando los desarrolladores trabajan en un proyecto alojado en GitHub, crean commits para guardar sus cambios. Estos commits están vinculados a un mensaje descriptivo que resume los cambios realizados en esa instantánea.

La plataforma GitHub proporciona una interfaz web y una variedad de herramientas que facilitan la visualización y el seguimiento de la historia de commits de un repositorio. Esto incluye la posibilidad de explorar el historial de commits, ver diferencias entre versiones, revisar el autor y la fecha de cada commit, y más.

Con el tiempo, GitHub ha seguido evolucionando y agregando características para facilitar la colaboración, como solicitudes de extracción (pull requests), revisión de código, gestión de problemas, integración continua y mucho más. Estas características han hecho que GitHub sea una herramienta fundamental para el desarrollo de software y proyectos de código abierto en todo el mundo.

En resumen, la historia del commit en GitHub está conectada al desarrollo de Git y a la creación de GitHub como una plataforma líder para alojar repositorios de código, facilitando así la colaboración y el seguimiento del progreso en proyectos de desarrollo.

¿Qué es?

En GitHub, un “commit” se refiere a una acción específica de guardar o confirmar los cambios realizados en un repositorio de código. Un repositorio es un espacio donde se almacenan todos los archivos y el historial de cambios de un proyecto, y un commit representa una instantánea de esos cambios en un punto específico en el tiempo.

Cuando trabajas en un proyecto alojado en GitHub, normalmente realizas modificaciones en los archivos de código o en otros elementos del repositorio, como documentos, imágenes, etc. Una vez que has realizado los cambios deseados, debes “confirmar” esos cambios utilizando un commit. Cada commit debe ir acompañado de un mensaje que describa brevemente los cambios realizados.

¿Qué lo hace especial?

Los commits son una parte esencial del control de versiones y permiten mantener un historial ordenado de todas las modificaciones realizadas en un proyecto. Esto ofrece varias ventajas:

1. Historial transparente: Cada commit registra qué cambios se realizaron, cuándo y quién los hizo, lo que facilita el seguimiento de la evolución del proyecto.
2. Reversión de cambios: Si en algún momento se introducen errores o se desean deshacer cambios anteriores, se puede volver a un commit anterior para restaurar el proyecto a un estado previo.
3. Colaboración eficiente: Los commits facilitan la colaboración entre desarrolladores en un proyecto compartido, ya que permiten trabajar en diferentes ramas y fusionar cambios de manera controlada.
4. Documentación del progreso: Los mensajes de commit suelen describir las mejoras o correcciones realizadas, lo que ayuda a mantener una documentación actualizada de los avances y decisiones tomadas en el proyecto.

¿Cómo es su funcionamiento?

1. Creación y modificación de archivos: Cuando trabajas en un proyecto alojado en GitHub, realizas cambios en los archivos del repositorio, ya sea creando nuevos archivos, modificando los existentes o eliminando algunos.
2. Área de preparación (Staging Area): Una vez que has realizado los cambios en los archivos, Git te permite seleccionar qué cambios deseas incluir en el próximo commit. Los cambios seleccionados se agregan al área de preparación o staging area. Esta es una etapa intermedia entre los cambios realizados y el commit real, lo que te permite revisar y organizar los cambios antes de confirmarlos.
3. Crear un commit: Una vez que tienes los cambios organizados en el área de preparación, estás listo para crear el commit. Un commit es una instantánea de los cambios seleccionados en ese punto específico del tiempo.
4. Asignar un mensaje al commit: Cada commit debe tener un mensaje descriptivo que explique brevemente los cambios que has realizado. Este mensaje es importante porque ayuda a otros colaboradores a entender qué se ha modificado y por qué.
5. Confirmar los cambios: Al confirmar los cambios, Git crea una nueva referencia o “apuntador” que apunta al commit recién creado. Esta referencia es una rama (branch) o una etiqueta (tag) que identifica el commit y lo hace accesible para futuras referencias y seguimiento.
6. Historial de commits: Cada commit creado en GitHub se agrega al historial de commits del repositorio. El historial muestra todos los commits realizados en orden cronológico, junto con sus mensajes y detalles de autoría.
7. Trabajar con repositorio remoto: Una vez que has realizado los commits en tu repositorio local, puedes sincronizarlos con el repositorio remoto en GitHub. Esto se hace utilizando el comando git push. De esta manera, los commits y sus cambios se reflejan en el repositorio remoto para que otros colaboradores puedan verlos y acceder a ellos.

Ejemplos

Ejemplo 1: Crear un nuevo archivo y hacer un commit:

1. Crear un nuevo repositorio en GitHub e inicializarlo con un archivo README.md.
2. Clonar el repositorio en tu máquina local usando el comando  git clone <URL_del_repositorio>
3. Agregar un nuevo archivo llamado nuevo_archivo.txt en el repositorio local con algún contenido.
4. Verificar el estado de los cambios realizados con git status.
5. Agregar el nuevo archivo al área de preparación con git add nuevo_archivo.txt
6. Realizar el commit con un mensaje descriptivo: git commit -m “Agregado el archuvo nuevo_archivo.txt”.
7. Sincronizar los cambios en el repositorio remoto en GitHub con git push origin master.

Ejemplo 2: Modificar un archivo existente y hacer un commit:

1. Clonar un repositorio existente de GitHub en tu máquina local.
2. Modificar un archivo llamado “archivo.txt” con algún contenido nuevo.
3. Verificar el estado de los cambios realizados con git status.
4. Agregar las modificaciones del archivo al área de preparación con git add archivo.txt.
5. Realizar el commit con un mensaje descriptivo: git commit -m “Actualizado el contenido del archivo.txt”.
6. Sincronizar los cambios en el repositorio remoto en GitHub con git push origin master.

Ejemplo 3: Trabajar en una nueva característica usando ramas:

1. Clonar un repositorio existente de GitHub en tu máquina local.
2. Crear una nueva rama para trabajar en la nueva característica: git checkout -b nueva_caracteristica.
3. Realizar cambios y agregar nuevos archivos relacionados con la nueva característica.
4. Agregar los cambios al área de preparación con git add . .
5. Realizar el commit con un mensaje descriptivo: git commit -m “Agregada nueva caracteristica”.
6. Sincronizar la nueva rama en el repositorio remoto en GitHub con git push origin nueva_cracteristica
7. Crear una solicitud de extracción (pull request) en GitHub para que los cambios de la nueva característica sean revisados y fusionados con la rama principal.

¿Cómo es Git commit frente a SVN commit? ¿Cuál es mejor?

La elección entre Git commit y SVN commit depende de varios factores, incluyendo las necesidades del proyecto, las preferencias del equipo de desarrollo y las características específicas de cada sistema de control de versiones. Aquí hay algunas comparaciones entre Git commit y SVN commit:

1. Sistema de control de versiones:

• Git es un sistema de control de versiones distribuido, lo que significa que cada desarrollador tiene una copia completa del historial del proyecto en su máquina local. Esto permite trabajar de forma independiente y sin conexión a internet. Los commits se almacenan localmente hasta que se sincronizan con el repositorio remoto.
• SVN es un sistema de control de versiones centralizado, donde hay un único repositorio central que almacena el historial del proyecto y los desarrolladores deben estar conectados al repositorio para realizar commits.

2. Flexibilidad en las ramas:

• Git es conocido por su flexibilidad en el manejo de ramas (branches). Los desarrolladores pueden crear fácilmente ramas para trabajar en características nuevas o correcciones de errores sin afectar la rama principal (branch). Luego, pueden fusionar los cambios de una rama a otra de manera controlada.
• SVN también permite trabajar con ramas, pero el proceso es menos flexible y más pesado en comparación con Git.

3. Velocidad y rendimiento:

• Git es generalmente más rápido en operaciones locales debido a su naturaleza distribuida y a que no requiere una conexión constante al repositorio remoto.
• SVN puede tener un rendimiento ligeramente más lento, especialmente en operaciones que involucran el repositorio central.

4. Historial y metadatos:

• Git almacena toda la información del historial del proyecto localmente, incluyendo los cambios completos en cada commit, lo que facilita la navegación y exploración del historial.
• SVN almacena solo la diferencia entre commits en el repositorio central, lo que puede requerir una conexión al servidor para acceder a la historia completa del proyecto.

5. Compatibilidad con grandes proyectos:

• Git es ampliamente utilizado en proyectos grandes y complejos debido a su capacidad de manejar eficientemente el versionado distribuido y la gestión de ramas.
• SVN también se usa en proyectos grandes, pero puede tener desafíos con ciertas operaciones en proyectos de escala masiva.