Git para analistas: control de versiones


Froggy Jumps Git para analistas: control de versionesVersion en ligne Guía rápida de Git par Universidad FUCS 1 ¿Cuáles son los tres espacios de Git mencionados y su función básica? a Ramas, etiquetas y copias; más el espejo remoto b Espacios de trabajo, área de ensayo (staging) y repositorio; más el remoto c Espacios de desarrollo, archivado y servidor; más el local 2 ¿Qué debe contener un buen mensaje de commit? a Un comentario claro de por qué se hizo el cambio (y respaldo con explicación si es necesario) b La fecha y hora exacta del cambio c Una enumeración de archivos modificados 3 ¿Qué tipo de datos nunca deben versionarse en Git? a Archivos de código fuente b Imágenes de alta resolución c Datos personales y credenciales 4 ¿Qué enfoque ayuda a evitar conflictos al trabajar en equipo? a Trabajar en la misma rama todo el tiempo b Dividir por archivos/módulos, integraciones frecuentes y estilo de código acordado c Evitar revisar cambios y solo hacer commits grandes 5 ¿Qué se recomienda respecto a la versión de datos crudos en repositorios? a Subir siempre los datos crudos para reproducibilidad b Almacenar los datos en la misma carpeta del código c Excluir datos crudos, pero documentar su origen y ubicación de obtención 6 ¿Qué es una rama en Git? a Un backup automático de archivos b Una etiqueta de versión única c Una línea de trabajo paralela para desarrollar cambios sin afectar la versión funcional 7 ¿Qué es una “pull request” o solicitud de integración? a Un comando de Git para fusionar automáticamente sin revisión b Revisión por pares para leer, comentar y aceptar cambios antes de fusionarlos c Una solicitud para borrar una rama 8 ¿Qué debe evitarse al fusionar cambios para facilitar revisión futura? a Revisar línea por línea antes de fusionar b Acumular semanas de cambios sin revisión c Usar herramientas de formateo automático 9 ¿Qué regla ayuda a mantener el proyecto legible ante cambios de formato? a Fijar una guía de estilo y usar formateo automático b Cambiar la guía de estilo en cada commit c Ignorar diferencias de estilo 10 ¿Qué recomienda la lectura para manejar grandes datos sin versionarlos en Git? a Incluir datos en el README b Usar un repositorio de datos con identificador persistente y enlazar desde README c Subir datos grandes al repositorio para acceso rápido

1

¿Cuáles son los tres espacios de Git mencionados y su función básica?

a

Ramas, etiquetas y copias; más el espejo remoto

b

Espacios de trabajo, área de ensayo (staging) y repositorio; más el remoto

c

Espacios de desarrollo, archivado y servidor; más el local

2

¿Qué debe contener un buen mensaje de commit?

a

Un comentario claro de por qué se hizo el cambio (y respaldo con explicación si es necesario)

b

La fecha y hora exacta del cambio

c

Una enumeración de archivos modificados

3

¿Qué tipo de datos nunca deben versionarse en Git?

a

Archivos de código fuente

b

Imágenes de alta resolución

c

Datos personales y credenciales

4

¿Qué enfoque ayuda a evitar conflictos al trabajar en equipo?

a

Trabajar en la misma rama todo el tiempo

b

Dividir por archivos/módulos, integraciones frecuentes y estilo de código acordado

c

Evitar revisar cambios y solo hacer commits grandes

5

¿Qué se recomienda respecto a la versión de datos crudos en repositorios?

a

Subir siempre los datos crudos para reproducibilidad

b

Almacenar los datos en la misma carpeta del código

c

Excluir datos crudos, pero documentar su origen y ubicación de obtención

6

¿Qué es una rama en Git?

a

Un backup automático de archivos

b

Una etiqueta de versión única

c

Una línea de trabajo paralela para desarrollar cambios sin afectar la versión funcional

7

¿Qué es una “pull request” o solicitud de integración?

a

Un comando de Git para fusionar automáticamente sin revisión

b

Revisión por pares para leer, comentar y aceptar cambios antes de fusionarlos

c

Una solicitud para borrar una rama

8

¿Qué debe evitarse al fusionar cambios para facilitar revisión futura?

a

Revisar línea por línea antes de fusionar

b

Acumular semanas de cambios sin revisión

c

Usar herramientas de formateo automático

9

¿Qué regla ayuda a mantener el proyecto legible ante cambios de formato?

a

Fijar una guía de estilo y usar formateo automático

b

Cambiar la guía de estilo en cada commit

c

Ignorar diferencias de estilo

10

¿Qué recomienda la lectura para manejar grandes datos sin versionarlos en Git?

a

Incluir datos en el README

b

Usar un repositorio de datos con identificador persistente y enlazar desde README

c

Subir datos grandes al repositorio para acceso rápido

Froggy Jumps