Quiz de Git

Sistemas de control de versiones y flujos de trabajo en Git

1. Los sistemas de control de versiones pueden ser locales, centralizados o distribuidos.

2. Los sistemas locales tienen una única base de datos que se almacena localmente.

3. Los sistemas centralizados almacenan el histórico de cambios en un servidor al que los desarrolladores se conectan.

4. Los sistemas distribuidos no tienen un único servidor que almacene la base de datos con el histórico de cambios, sino que cada cliente almacena una copia del repositorio junto al histórico de cambios.

5. Los sistemas distribuidos suelen ser más rápidos y permiten colaborar con facilidad.

6. Git es el sistema distribuido más usado actualmente.

7. Los flujos de trabajo en Git pueden ser centralizados o de ramas por características.

8. El flujo centralizado es sencillo y consiste en que todos los desarrolladores trabajen sobre una única rama.

9. El flujo centralizado funciona tanto en sistemas centralizados como distribuidos.

10. El flujo de ramas por características se utiliza cuando las nuevas características requieren desarrollos largos.

11. En este flujo se crean ramas nuevas para cada nueva característica que se fusionan con una rama de integración.

12. La rama de integración se asegura de que la construcción, el empaquetado y las pruebas funcionen correctamente antes de fusionarse con la rama principal.Flujos de trabajo en Git y GitHub

13. Existencia de diferentes estrategias de ramificación en Git para facilitar el trabajo en equipo y la gestión de versiones.

14. La estrategia de ramificación Feature Branching consiste en crear ramas para cada nueva característica o arreglo, fusionándolas después con la rama de integración y finalmente con la rama master.

15. La estrategia Gitflow es una extensión de la anterior, definiendo diferentes tipos de ramas con una nomenclatura estricta, tales como master, develop, feature, release y hotfix.

16. El flujo de trabajo de GitHub o Forking Workflow difiere de los anteriores al requerir que cada desarrollador disponga de un repositorio remoto propio y utilizar las pull requests para fusionar cambios en la rama master.

17. En el Forking Workflow, los desarrolladores crean un fork a partir del repositorio principal, clonan su fork a su equipo, crean una rama nueva en su repositorio local, editan los ficheros necesarios, añaden los commits a su rama local, suben la rama a su repositorio remoto, inician una nueva pull request entre forks, los administradores revisan la petición, pueden desplegar un entorno de prueba con el código de la pull request, y finalmente, fusionan los cambios en master.

18. La estrategia de State Branching o GitLab Flow consiste en nombrar las ramas según el entorno en el que se despliegan, fusionando cada rama con la siguiente cuando el código está listo para ser promocionado al siguiente entorno.

19. Cada flujo de trabajo se puede adaptar a las necesidades del equipo y existen flujos híbridos y adaptaciones de flujos conocidos.

20. La elección del flujo de trabajo dependerá de factores como la complejidad del proyecto, el equipo de trabajo, la frecuencia de liberación de versiones y la estrategia de despliegue.

21. Git permite resolver conflictos entre ramas mediante la descarga de los cambios de una rama, la resolución de conflictos y la aplicación de los cambios en el HEAD de la rama.

22. Las pull requests permiten la revisión y aprobación de cambios antes de su fusión en la rama principal, lo que mejora la calidad del código y reduce errores.

23. GitHub y Bitbucket ofrecen un sistema de control de versiones distribuido que permite el trabajo colaborativo y la gestión de versiones de forma eficiente.

24. La elección de una estrategia de ramificación adecuada y un flujo de trabajo eficiente es fundamental para el éxito de un proyecto de software y