Viajando en el tiempo con Git

Algunas cosas pueden salir mal

• Borrar un archivo
• Olvidar qué fue lo último que hice y cuándo
• Editar/eliminar la parte equivocada
• Olvidar porqué edite/eliminé esa parte
• Compartirlo con alguien más
• Explicar porqué edité/eliminé esa parte

Solución

Tener todo la información en el presente es un caos

Tener una máquina del tiempo

Todo puede salir muy mal

• Trabajar todos al mismo tiempo
• Unir los cambios
• Quién hizo qué

Solución

Tener todo la información y todas las personas en el presente es un caos

Tener muchas máquinas del tiempo

¡Una máquina del tiempo!

Un sistema de control de versiones

Pero muy parecido a una máquina del tiempo

Repositorio (repo)

• Es nuestro proyecto
• Tenemos repos locales y remotos

Commit

• Un punto de restauración (snapshot) de nuesto proyecto
• Cada commit está identificado por un hash (SHA-1)

a906cb2a4a904a152e80877d4088654daad0c859.

Los 3 estados

• Área de trabajo (working directory)
• Área de staging (staging area)
• Área del repositorio (repo area)

Los 3 estados

• Working directory (los archivos editados)
• Staging area (cambios a ser guardados)
• Repo area (cambios guardados)

Los 3 estados

                
                  git status
                
              

Archivos nuevos no son registrados por Git (untracked).

Cambios a ser guardados

                
                  git add <archivo>
                
              

Guardar nuestros cambios

                
                  git commit
                
              

              
                # Ver todos nuestros commits
                git log

                # Ver un commit específico
                git show <hash>
              
            

• Archivos autogenerados
• Archivos sensibles (contraseñas, configuraciones de producción)
• Archivos del sistema operativo (*~, .DS_Store, Thumbs.db)

              
                # Archivo .gitignore

                # Archivos del SO
                *.DS_Store
                *~
                Thumbs.db

                # Otros archivos
                build/
                passwords.txt
              
            

• Un repo que está en otro lado
• Cuando hacemos un clone, se crea uno
• Podemos agregar varios remotos
• Nos sirven para interactuar con otros repos

              
                # Listar remotos
                git remote -v

                # Agregar un remoto
                git remote add <nombre> <url>
                
                # Eliminar un remoto
                git remote remove <nombre>
              
            

• Nos permiten trabajar de manera paralela
• Experimentar con nuevas características
• Podemos mezclar los cambios a nuestra rama principal
• Ideal para trabajar con otras personas
• Por defecto tenemos una rama main o master

              
                # Crear una rama basada en la rama actual
                git branch <nombre> 

                # Cambiar entre ramas
                git checkout <nombre> 

                # Crear y cambiar a esa rama
                git checkout -b <nombre> 
              
            

Si tenemos cambios que no hemos guardado (commit). Y queremos cambiar de rama/commit, Git se quejará.

              
                # Guardar nuestros cambios sin confirmar
                git stash

                # Volver a aplicar nuestros cambios
                git stash pop
              
            

Nuestra nueva funcionalidad funciona. Tiempo de mezclarla a nuestra rama principal.

              
                # Cambiar a la rama base
                git checkout <rama base>

                # Mezclar nuestras ramas
                git merge <otra rama>
              
            

Conflictos al mezclar

• Cuando en ambas ramas se modificaron las mismas líneas de un archivo
• Basta con abrir el archivo y buscar las marcas especiales
• Quedarnos con los cambios necesarios
• Hacer un git add para marcar los conflictos como resueltos
• Hacer un commit para continuar con el merge