0% encontró este documento útil (0 votos)
14 vistas6 páginas

Introducción a Git y Control de Versiones

Git es un sistema de control de versiones que permite registrar los cambios realizados en un proyecto. Los desarrolladores crean commits para registrar sus cambios. Pueden trabajar de forma distribuida en ramas para luego fusionar su trabajo en la rama principal. Esto permite trabajar de forma aislada y en equipo de manera flexible.

Cargado por

Bech Avila
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
14 vistas6 páginas

Introducción a Git y Control de Versiones

Git es un sistema de control de versiones que permite registrar los cambios realizados en un proyecto. Los desarrolladores crean commits para registrar sus cambios. Pueden trabajar de forma distribuida en ramas para luego fusionar su trabajo en la rama principal. Esto permite trabajar de forma aislada y en equipo de manera flexible.

Cargado por

Bech Avila
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

GIT (Sistema Control de Versiones)

Git es un software que permite registrar todo el historial de cambios del proyecto.

TERMINOLOGÍAS:
1. REPOSITORIO
Es todo proyecto que está siendo seguido por Git, ya tienen un historial de Git en
la que se están registrando sus cambios.

2. COMMIT
 Es cada uno de los cambios registrados en el historial de Git.
 Cada uno de los desarrolladores manda los Commit de los cambios que ha
hecho.
 El desarrollador le dice a Git, yo hice estos cambios y lo hice por estos
motivos.

3. RAMAS
 Son ramificaciones, bifurcaciones o nuevos caminos que toma el proyecto.
 En Git todo se trabaja por ramas, la rama principal se llama MASTER y es
ahí donde está el proyecto que sale al público (versión en producción).
 Cada vez que se quiere trabajar en una nueva característica o corregir algo
se saca una rama, de tal manera que puedas trabajar en un ambiente
aislada, una rama es una copia exacta del proyecto pero separada.
 Si todo va bien la rama se unifica en el proyecto principal y si va mal se
puede eliminar la rama sin ningún problema.
4. CLON
 Es una copia exacta del REPOSITORIO.
 Cuando un programador se integra a un equipo de trabajo, lo primera que
tiene que hacer es CLONAR EL REPOSITORIO en su equipo local.
 Cada uno de los desarrolladores tiene un CLON del REPOSITORIO en su
equipo local.

5. FORK
 A diferencia de un CLON o de una RAMA es un proyecto completamente
diferente que se crea a partir de otro.
CARACTERÍSTICAS:
1. DISTRIBUIDO
 No necesitan conectarse un servidor central.
 Tampoco necesitan conexión a internet para trabajar.
 Cada desarrollador tiene un backup del proyecto.

2. RAMAS Y FUSIONES (BRANCH Y MERGE)


 Todas las ramas tienen que integrarse con la rama principal, a esto se le
conoce con FUSION o MERGE.
FLUJO DE TRABAJO:
1. CREAR REPOSITORIO.
 Cuando llega un desarrollador lo primero que tienen que hacer es crear un
repositorio.
 Hay 2 formas de crear repositorio:
A. Git init
 Si es un repositorio nuevo o desde cero.
 Ejemplo: Cuando vas a crear por primera vez el repositorio
del proyecto.
B. Git clone
 Si es un repositorio que ya existe.
 Ejemplo: Cuando llegas a integrarte a un proyecto.

2. STAGIN AREA (ÁREA DE PREPARACIÓN)


 Cuando hago cambios para corregir el error tengo que tocar 4 o 5 archivos,
y todos estos archivos los voy mandando al STAGIN AREA con el comando
“git add”.
 Una vez que se solucionó todos los errores mando los archivos al
REPOSITORIO con el comando “git commit”, y juntamente con el comando
git commit se agrega un mensaje donde digo “en este commit estoy
corrigiendo tal error ”.
3. TRABAJAMOS EN EQUIPO
 Si trabajamos en equipo, lo normal es tener 2 ramas:
Master. - esta rama se cuida y no se trabaja ahí
directamente.
Dev. - desde la rama DEV cada uno de los desarrolladores
va sacar sus propias ramas para trabajar en lo que le toca
a cada uno.
 Cuando el trabajo se completa por cada uno de los
desarrolladores las ramas deben volver a integrarse a DEV, esta
integración se llama MERGE.
 En los MERGE podría haber conflictos o cosas que fallen y eso es
riesgoso, entonces normalmente podría haber un líder de
proyecto quien se encargue de revisar que no haya conflictos y
devolverlo a los desarrolladores para que lo resuelvan.
 Finalmente, la rama Dev debe integrarse a la rama MASTER.
HERRAMIENTAS:
1. LÍNEA DE COMANDOS (TERMINAL).

2. CLIENTES GRÁFICOS.

3. REPOSITORIOS EN LA NUBE.

También podría gustarte