Git: Guía rápida para control de versiones

Git es uno de los sistemas de control de versiones más populares. El control de versiones es un tipo de sistema que le permite realizar un seguimiento de los cambios realizados en el código a lo largo del tiempo.

Como tal, el control de versiones es útil porque:

1. Puede volver a ‘versiones’ específicas de su código
2. La colaboración en el mismo trabajo es posible porque los cambios específicos y los contribuyentes asociados son rastreados

Como la codificación es una integral aspecto de la ciencia de datos, es una buena práctica usar control de versiones para mantener el código fuente y las bases de datos.

También optimiza proyectos colaborativos. Los cambios se pueden registrar en un repositorio: una estructura de datos que almacena archivos y un registro de los cambios realizados en esos archivos.

Es un sistema de control de versiones distribuidas . Los cambios no tienen que estar comprometidos con el mismo repositorio central, lo que requeriría que todas las personas que trabajan en el proyecto accedan a ese repositorio central y descarguen el último código para guardar los cambios. En cambio, todos pueden tener su propio repositorio localizado con todo su historial.

Como es, Git es una herramienta bastante sencilla que, junto con servicios como Github (alberga los repositorios de Git en la nube), facilita el control de versiones.

Pasos básicos de Git

Asegúrese de que Git esté instalado en su máquina.

Todos los comandos posteriores se ejecuten en el terminal y debe estar en el proyecto . directory .

Nota: todos los códigos futuros que requieran entradas especificadas por el usuario (como el archivo específico) se pondrán en cursiva.

 add  filename 

El código anterior significa que siempre escribe en ‘agregar’, pero debe especificar el archivo que desea agregar.

resumen general del proceso de edición-compilación-commit. los rectángulos delinean el ‘estado’ del archivo (s) en cuestión. cuando el archivo finalmente se confirma, volvemos al estado sin modificaciones hasta que estemos listos para realizar la etapa y confirmar más cambios.

1. Initialize Git Repository

Para inicializar un repositorio de Git en un directorio de proyecto:

 git init

Esto creará un directorio .git en el directorio del proyecto.

2. Comprobar estado del archivo

Para comprobar si se modificaron los archivos y aún no se ha confirmado,

 estado del git

Esto devolverá el estado actual del repositorio y se verá algo como esto:

Archivos que aún no están ‘ rastreado ‘(en etapas y / o cometido) se anotará aquí. Si se rastrean todos los archivos, entonces Git notará que no hay nada que confirmar y que el árbol de trabajo está limpio.

2a. Crear un archivo .gitignore

Un archivo .gitignore es importante para garantizar que los archivos con información confidencial (como contraseñas y claves de API personales) no sean rastreados. Esto es particularmente importante cuando / si elige enviar el repositorio a un servicio en la nube para que se pueda mostrar públicamente. Para crear el archivo .gitignore:

 toque .gitignore

En el archivo .gitignore, agregue los nombres de los archivos o las reglas generales que deciden los archivos que se ignorarán (consulte Octocat para obtener información bien definida). .gitignore rules).

Es una buena práctica agregar archivos a .gitignore antes de realizar commits. Agregar cualquier archivo a .gitignore asegurará que el archivo no se rastree en subsiguientes commits . Todas las confirmaciones anteriores con este archivo seguirán estando disponibles y el archivo deberá eliminarse de las confirmaciones más antiguas.

3. Cambios de los archivos de etapa

Puede organizar selectivamente los archivos modificados, agregándolos al ‘área de preparación’ para prepararlos para su confirmación. Los archivos modificados que no se agregan al área de ensayo no se comprometerán posteriormente. Esto permite confirmaciones más refinadas y específicas (por ejemplo, cambios en la parte A del proyecto solamente), que es útil para referencia futura.

 #para crear archivos modificados específicos 
 git add  nombre de archivo 

 # para organizar todos los archivos modificados 
 git add.

Se debe tener en cuenta que los commits se graban para la rama actual; esto se considera una bifurcación en la historia del proyecto.

4. Cambios de archivo (s) de confirmación (commit)

Se comprometen todos los archivos en etapas, creando esencialmente una “captura de pantalla” de esos archivos en particular en ese momento particular. Esto registra efectivamente un nuevo cambio en el repositorio.

 git commit -m & # 039;  describe los cambios realizados aquí  & # 039;

Cada compromiso debe hacerse con un mensaje que describa los cambios realizados. Esto se hace en tiempo presente y es mejor ser más descriptivo. Esto será útil al revisar los registros más adelante.

4a. Uso de compromisos anteriores

Puede ser muy útil verificar las confirmaciones pasadas, ya sea para ver qué cambios se han realizado desde entonces (para identificar potencialmente el origen de un nuevo error) o incluso para volver a una confirmación anterior.

Para mostrar un registro de todos los commits realizados:

 git log

Esto devolverá un registro de commits, donde cada commit se ve así:

Cada commit tendrá una descripción asociada (por eso las descripciones durante los commits son importante), hora e identificación de compromiso. HEAD se refiere a la rama actual que, en este caso, es el maestro.

Para verificar los cambios realizados en una confirmación específica:

 git show  commit-id 

La ID de confirmación también se conoce como un hash (generado aleatoriamente).

Para volver completamente a una confirmación previa:

 git reset --hard  commit-id 

Esto esencialmente volverá a la confirmación especificada (y los archivos en ese compromiso particular); todos los cambios desde esa confirmación se perderán y HEAD apunta a la confirmación especificada. Si no se incluye la opción “- difícil”, se producirá un restablecimiento parcial; todos los cambios serán retenidos como cambios no escalonados y HEAD apunta a la confirmación especificada.

Antes de seguir adelante, es importante describir la ramificación, que es un aspecto fundamental de Git.

Ramificación

Una rama es esencialmente un directorio ‘nuevo’, en el que puede trabajar en una parte específica o característica de un proyecto, antes de fusionar esos cambios con la rama principal que contiene toda su fuente código.

La ​​rama predeterminada con la que siempre comienza siempre se denomina rama maestra. La rama principal contiene el código fuente más actualizado y disponible. Siempre suponga que la rama principal está lista para ser desplegada. Toda la experimentación y los cambios, grandes y pequeños, se realizan en otras ramas para fusionarse posteriormente.

Pasos básicos

Para enumerar todas las ramas en el repositorio:

 git branch

Para crear una nueva rama :

 git branch  new-branch-name 

Esto solo creará la rama. Para cambiar a una rama específica y comenzar a trabajar en ella:

 git checkout  another-branch 

Como alternativa, si desea crear una nueva rama y cambiarla inmediatamente a ella:

 git checkout -b  nombre-nueva-rama 

Fusionar ramas

Para fusionar dos ramas (en su repositorio local) como una rama de entidad y la rama principal:

1. Asegúrese de estar en la sucursal receptora (el maestro recibiría de la rama de características)

 git checkout  maestro 

2. Tanto la característica como las ramas maestras deben estar completamente actualizadas, incluso con cambios remotos.

Para extraer y fusionar los cambios remotos más recientes:

 git pull

3. Para fusionar la rama de entidad en la rama principal:

 git merge  feature-branch 

4. Elimine la rama de características ahora irrelevante

 git branch -d  feature-branch 

Trabajando con Github

Asegúrese de tener una cuenta Github y que tenga creó un repositorio de Github para su proyecto. A continuación, puede enviar un repositorio local a este repositorio.

Alternativamente, puede clonar un repositorio existente, que esencialmente crea una copia del repositorio público en su máquina. (git clone filepath)

Cuando clona, ​​se crea automáticamente una conexión remota (conocida como ‘origen’) al repositorio original. Esto le permite empujar y tirar de los cambios (hacia y desde el repositorio original) en el futuro.

La ​​principal utilidad de Github es que agiliza el trabajo colaborativo. Todos los colaboradores de un proyecto pueden tener su propio repositorio privado local para el proyecto, realizar cambios en su repositorio local y enviar cambios al depósito público más adelante. Pueden hacer todo esto sin tener que estar al día con los cambios realizados en el repositorio público.

README.md

Un archivo léame es integral para un repositorio público, ya que es útil para describir el proyecto, identificar errores y enumerar dependencias , etc. RociosNG tiene una buena guía sobre lo que debe incluirse en un archivo Léame para un proyecto de ciencia de datos. Normalmente se crea como README.md.

General Git Workflow

¿Cómo se ve el flujo de trabajo general de Git ? Esto variará, dependiendo del equipo y proyecto, pero cada flujo de trabajo comienza con un repositorio público almacenado en un servidor (comúnmente, Github) y depende de la bifurcación. El flujo de trabajo de Git más fundamental y sencillo de explicar es un flujo de trabajo centralizado. Muchos otros flujos de trabajo son simplemente una extensión del flujo de trabajo centralizado.

Un flujo de trabajo centralizado depende de un único depósito público.

1. Los colaboradores clonan el depósito central de Github, creando así copias del repositorio en sus máquinas locales. (git clone repository)

2. Luego pueden crear su propia sucursal en su repositorio local, donde pueden crear, escenificar y confirmar sus cambios localmente.

 git checkout -b  branch 

3. Luego pueden enviar esos cambios (confirmados) a la versión remota de su rama en Github (aún separada de la rama remota maestra).

 La versión local #ensure del maestro está actualizada 
 git pull - maestro de origen de rebase

 #push a branch remoto 
 git push origin  branch 

4. Una vez que el colaborador está listo, puede enviar una solicitud de extracción para su sucursal remota. Otros colaboradores pueden revisar los cambios y una vez que se aprueben los cambios, esos cambios pueden combinarse con la rama remota maestra.

Si hay conflictos, Git generará un mensaje de error y los conflictos deberán resolverse mediante el colaborador. Una vez que se resuelven los conflictos, los cambios pueden realizarse con éxito.

Resolviendo Conflictos

Debido a que los contribuyentes están realizando cambios en sus repositorios locales, su código puede entrar en conflicto con el de otros colaboradores una vez que esos cambios se envían a un repositorio central.  Supongamos que dos colaboradores trabajan en el mismo archivo y ambos cambian la línea 13 de diferentes maneras. Si se realiza el mismo cambio, no habrá conflicto. Si los cambios son diferentes, entonces puede surgir un conflicto. Normalmente Git trataría de combinar los cambios de una manera inteligente, pero cuando no puede determinar qué cambio debe integrarse (si no se pueden incluir ambos), entonces el conflicto debe resolverse manualmente.

1. Extraiga todos los cambios nuevos del repositorio central

 git pull --rebase origin master

Esto hará que todos los cambios sean enviados al repositorio central ya que el contribuyente lo clonó. Esto actualizará la rama maestra.

Al incluir la opción rebase las confirmaciones que se realizaron localmente se agregan a la nueva rama maestra actualizada. Esto esencialmente reescribirá el historial de proyectos de la rama maestra; todas las confirmaciones locales ahora forman parte de su historial de proyectos.

Esto dará como resultado un historial de proyecto más limpio, sin bifurcaciones ni compromisos de fusión extraños. Esto es más fácil para referencia futura.

2. Resolver conflictos

Rebasing agrega una confirmación a la vez al historial de proyectos de la rama maestra. Al hacerlo, cualquier conflicto también surgirá. Esto facilita la resolución de conflictos porque pueden tratarse caso por caso.

Debido a que la ciencia de datos se caracteriza por el trabajo colaborativo que a menudo requiere codificación, es importante aprender y practicar el control de versiones. Sentí que sería más útil debatir sobre Git, ya que actualmente es el sistema de control de versiones más popular. Cabe señalar que no es el único sistema de control de versiones. Sin embargo, es importante al menos comprender el control de versiones y algún sistema de control de versiones.

Esta fue una descripción general muy amplia de los elementos esenciales de Git. Para obtener más recursos en profundidad, consulte a continuación.

Recursos

• DataCamp
• GitHowTo
• Documentación de Git
• Further Git & Github practice
• Tutorial de Atlassian Git
• Github Flow