Git & GitHub Part I

Git & Github I
Max Cruz
https://www.linkedin.com/in/max-cruz/
https://github.com/maxcruz

Agenda
● Git & GitHub
● Breve historia de Git
● ¿Por qué Git/GitHub?
● Compartiendo el trabajo
● Contribuyendo a un proyecto (Forking)
● Trabajo en paralelo (Branching)
● Construyendo el cambio (Commit)
● Entregar respetuosamente (Pull Request)
● Calidad en el código (Code Review)
● Uniendo el trabajo (Merge)
● Probar Git

Git & GitHub
Git:
Un sistema de control de versiones.
Alternativas: Mercurial, CVS, SVN.
GitHub:
Una plataforma de desarrollo de software
colaborativo.
Alternativas: GitLab, BitBucket.

Git: The Three States
Git tiene tres estados principales en los que pueden
residir tus archivos:
Committed significa que los datos se almacenan de
forma segura en su base de datos local.
Modified significa que ha cambiado el archivo pero
aún no lo ha enviado a su base de datos.
Staged significa que ha marcado un archivo
modificado en su versión actual para ir a su próximo
commit snapshot.

Distributed Version Control Systems

Breve historia de Git
Desarrollado por Linus Torvalds en 2005 para ser
usado como el sistema de control de versiones del
kernel de Linux como una alternativa a DVCS
(BitKeeper).
- Velocidad
- Diseño simple
- Un soporte fuerte para desarrollo no lineal
- Completamente distribuído
- Capacidad para manejar grandes proyectos

¿Por qué Git/GitHub?
- Popularidad
- Documentación
- Integración
- Aprender y experimentar
- Notificaciones
- Compartir software
- Registro de incidencias
- Mostrar tus conocimientos

Compartiendo el trabajo
- El código al alcance de todos.
- Compartir software con el mundo.
- Los conflictos no son un problema.
- Los proyectos siempre debe tener uno o varios dueños.
- La calidad del código es responsabilidad de todos.
- Entregar, integrar y desplegar continuamente.

Contribuyendo a un proyecto (Forking)
La palabra fork se traduce, dentro del contexto
como bifurcación. Cuando hacemos un fork de un
repositorio, se hace una copia exacta que podemos
utilizar de forma segura.
Hacer un fork no es lo mismo que clonar.
Permite que todos puedan contribuir sin tener
permisos de escritura en el repositorio principal.

Trabajo en paralelo (Branching)

Construyendo el
cambio (Commit)
Cada commit debe ser un cambio
lógico que aporta a la construcción
del propósito del branch.
Algunos consejos:
- Haga commit rápido y seguido a su
branch local.
- Sincronice el branch con su fork
frecuentemente.
- Defina un estándar para nombrar sus
branch.
- Haga uso de comentarios descriptivos
en sus commits.
- Mientras construye un cambio, en su
fork no es necesario que el código
funcione.

Entregar respetuosamente (Pull Request)
Cuando finaliza de desarrollar el brach y lo sincroniza con su fork, debe
enviar una solicitud (pull request) para que su código sea revisado e
integrado en el repositorio principal.
Un pull request siempre debería de ser un cambio funcional y completo.
Es ideal que cada pull request lleve una descripción clara de su
propósito y los cambios realizados para facilitar la revisión del código.

Calidad en el código (Code Review)

● Cualquier desarrollador debe estar abierto a recibir críticas constructivas en su código
y puede hacerlas en el de otros.
● El code review es una excelente oportunidad para aprender buenas prácticas de
desarrollo.
● Deje el ego de lado, es menos vergonzoso que su compañero le advierta un error en
el código a que lo haga el usuario final.
● Mueva las mejoras que no puedan realizarse a tickets de deuda técnica.

Try Git
https://try.github.io/levels/1/challenges/1

Bibliografía
Pro Git
Por Scott Chacon y Ben Straub
Link Amazon: http://a.co/9FJngxD
Link Gratis: https://git-scm.com/book/en/v2

Git & GitHub Part I

Más contenido relacionado

La actualidad más candente

Similar a Git & GitHub Part I

Git & GitHub Part I