Git es un sistema de control de versiones distribuido gratuito y de código abierto diseñado para gestionar todo tipo de proyectos de pequeño y gran tamaño, con velocidad y eficiencia.
En este artículo voy a describir a modo de referencia los comandos Git habituales que debe conocer todo data engineer.
Flujo de trabajo con Pull Request
1 - Bifurcar un proyecto en el que queramos contribuir (Fork)2 - Clonar el proyecto en nuestro sistema local (git clone)
$ git clone <url_repo> [<otro-dir>]
3 - Crear nueva rama de trabajo (tarea JIRA)
$ git checkout -b mi_rama
Ejemplo nombre de rama: BD2CF3-123_fix_TCS_bands
siendo BD2CF3-123 el código de la tarea JIRA y el resto la descripción de la tarea en inglés cambiando espacios por guiones bajos.
4 - Crear remoto para el repo ascendente
$ git remote add upstream https://...
5 - Hacer los cambios (desarrollo)
$ git status
$ git add .
$ git commit -m "xxxxx"
$ git commit --amend --no-edit (añade los cambios al commit más reciente sin cambiar el mensaje)
Para los comentarios se indica "feat: descripción" o "fix: descripción", donde la descripción se coje tal cual de la tarea JIRA y debe estar en inglés.
Por ejemplo: git commit -m "fix: BD2CF3-123 Fix TCS bands"
6 - Enviar los cambios a nuestro repo
$ git push origin mi_rama
$ git push --force origin mi_rama (envía los cambios al repo remoto con el mismo commit id)
7 - Hacer click en "New pull request" (nueva solicitud de extracción) y revisar los cambios
8 - Crear la pull request, marcar WIP si es necesario y asignar el revisor
RESUMEN DE COMANDOS GIT
# Deshace el cambio en Staging y lo regresa al working area.git reset HEAD <file>
# Deshace el cambio en el working area y regresa al cambio anterior en el sistema.
git checkout -- <file>
# borrar un fichero en GIT. Lo borra del working area y apunta una marca de borrado en staging.
# Se puede volver a restaurar el fichero en el sistema ejecutando un git reset HEAD <file> y un git checkout -- <file>
# Si lo borro directamente del sistema, la marca de borrado se pone en el working area y hay que hacer un add y un commit para confirmar el borrado.)
git rm <file>
# borra un directorio completo con todo su contenido.
git rm -rf <dir>
# renombrar ficheros. Poner una marca de renombrado en el staging y renombra efectivamente el fichero en el sistema.
# Si se renombra directamente desde el sistema, lo hace en 2 pasos, poniendo una marca de borrado en el working y añadiendo un nuevo fichero con
# un nombre nuevo en el working dir.
$ git mv <current_name> <new_name>
$ git mv <file> <dir> (mover ficheros. también funcionan con marcas de renombrado en staging cuando se hacen desde git.)
$ git log (ver historial de cambios con todos los commits junto a sus id's.
El id es un valor hash del commit)
$ git log --oneline --graph --decorate (saca el historial de cambios con 1 línea por cada commit, representando gráficamente todas las ramas)
$ git log --since="2 days ago" (saca los commits realizados en los últimos dos días)
$ git log -- <file> (Encontrar los cambios que hemos hecho en un fichero o directorio específico)
$ git show <commit-id> (sacar los detalles de un commit específico para ver sus cambios)
$ git help log (más información sobre el comando git log)
$ git log --all --graph --decorate --oneline (saca el historial de todos los commits con una representación gráfica sacando con un modo abreviado las refs en una única línea)
Para crear un alias tenemos que actualizar la configuración global de Git:
$ git config --global alias.<comando_corto> "comando largo"
Por ejemplo: $ git config --global alias.history "log --all --graph --decorate --oneline"
Luego podemos llamar al comando corto: $ git <comando_corto>
Por ejemplo: % git history (obtenemos la misma salida que invocando el comando largo)
Si nos hemos equivocado escribiendo el comando largo, podemos corregirlo editando el archivo .gitconfig.
Por ejemplo: $ subl ~/.gitconfig
Si queremos excluir un fichero del proyecto para que no haga commits tenemos que crear el directorio oculto .gitignore:
Por ejemplo: $ subl .gitignore
Tenemos que escribir el nombre del fichero que queremos excluir en .gitignore y luego añadir .gitignore al control de cambios con "git add" y "git commit"
El fichero que hemos indicado que vamos a excluir sigue presente en el sistema pero no se añade a ningún commit.
Esta característica se puede usar por ejemplo, para excluir logs, o ficheros binarios generados del control de cambios de Git.
Si queremos excluir múltiples ficheros del control de cambios de git, podemos incluir un patrón en .gitignore. Por ejemplo, *.log.
Para excluir múltiples ficheros de un directorio, podemos indicar el nombre del directorio en .gitignore. Por ejemplo, TestResources/
# Comparar entre el working directory y la staging area.
git diff
$ git diff <file> (Comparar los cambios entre el working y el staging para un fichero específico)
$ git diff HEAD (Comparar los cambios entre el working dir y el último commit del repositorio)
$ git diff HEAD <file> (Comparar los cambios entre el working dir y el último commit del repositorio para un fichero específico)
# Comparar el staging con el último commit del repositorio.
git diff --staged HEAD
# Comparar el staging con el último commit del repositorio para un fichero específico.
git diff --staged HEAD <file>
# Comparación después de un commit
# Con git log podemos ver el historial de commits y ahora queremos ver las diferencias que hay entre dos commits.
git diff <COMMIT-ID-1> <COMMIT-ID-2>
# Comparar cambios del último commit con el penúltimo commit (HEAD-1)
git diff HEAD HEAD~
# Comparar una rama local con una rama remota:
git fetch <remote> (es necesario para actualizar las referencias del repo remoto)
git diff <local branch> <remote>/<remote branch>
Por ejemplo:
git fetch origin
git diff b_encrypt origin/b_encrypt
# Trabajo con ramas en GIT
# Se puede usar git status para comprobar la rama en la que estamos y si estamos sincronizados con el origen o tenemos cambios pendientes.
# Necesitamos las ramas en el mundo real para trabajar en coordinación con otros desarrolladores.
# Por ejemplo, podemos dejar la rama master solo para escenarios de producción.
# Podemos crear una rama para cada tarea JIRA de un desarrollador (por funcionalidad), o basar cada rama en un sprint.
# Se suele tener una rama develop para integrar todos los cambios de desarrollo de una release.
# No es buena práctica hacer push en master, sino en develop.
# Listar las ramas en GIT (tanto locales como remotas, mostrando en cual nos encontramos actualmente.)
git branch -a
# Listar solo las ramas locales (sin el parámetro -a)
git branch
# Crear una rama
git branch <mi-rama>
# Cambiar a una rama en GIT
git checkout <mi-rama>
# Podemos crear una nueva rama y posicionarnos en ella con un solo comando:
git checkout -b <mi-rama>
# Renombrar una rama
git branch -m <mi-rama> <mi-rama-renombrada>
# Si estoy en la rama que quiero renombrar:
git branch -m BD2CF3-123_fix_TCS_bands
# siendo BD2CF3-123 el código de la tarea JIRA y el resto la descripción de la tarea en inglés cambiando espacios por guiones bajos.
# Borrar una rama
# No se puede borrar la rama en la que estamos posicionados actualmente.
# Se crea un commit de borrado de la rama que podemos verificar con git log
git branch -d <mi-rama>
# Los cambios en una rama aparecen en staging de develop cuando se hace git add, ya que el working dir es el mismo.
# Los cambios que confirmemos con git commit en una rama no aparecen en develop.
# Para hacer un merge tenemos que posicionarnos primero en la rama objetivo.
# Por ejemplo, si vamos a hacer un merge de develop a master, nos colocamos primero en master.
git checkout master
git merge develop
# Si aparece Fast-forward en la salida del git merge significa que no ha habido que resolver conflictos, por lo que solo ha movido directamente los commits
# de develop a master.
# Merge automático en GIT => Son los merges que se pueden resolver sin intervención manual.
# Antes de hacer un merge podemos revisar el historial de commits con git log y revisar los cambios en la rama.
# Nos posicionamos primero en la rama objetivo y hacemos el merge con la rama fuente.
git checkout master
git merge develop -m "xxxxxxxxxxxxxxx"
# Después de un merge, ejecutar de nuevo el comando git log para verificar el merge con la rama
git log --online --graph --decorate --all
# Verificar los cambios aplicados en la rama objetivo con el editor de código
# Para sincronizar mi rama con los últimos cambios en develop se puede usar git rebase
# git rebase es más limpio que un merge, por lo que es preferible siempre que sea posible
1 - git checkout develop
2 - git pull upstream develop
3 - git push origin develop
4 - git checkout <mi-rama>
5 - git rebase develop
6 - Comprobar con tig o git log
# Otra forma de actualizar la rama local develop
# 1 - Refresh changes in upstream
git fetch upstream
# 2 - Bring new changes (if there is any) into local
git pull --rebase upstream develop
# 3 - Upload changes into our origin
git push --force origin develop
# Abre un editor y edita el texto para explicar para que sirve una rama, para ser utilizado por otros comandos distintos.
git branch --edit-description
# Añadir upstream como origen, que sera necesario para actualizar el proyecto, y sera donde se realice la pull-request
git remote add upstream <ssh-URL>
git remote add gitlab <https-URL>
GIT TAG
Un tag es una referencia que apunta a un commit que se usa para marcar una versión entregable, p.e., v1.0.1git tag <tag_name> => para crear una etiqueta en el último commit. Se puede revisar con git log o con tig
git tag --list
git tag --delete <tag_name>
BAJARSE UN TAG DE UNA RELEASE PARA CHEQUEARLA
$ git fetch --all --tags
$ git checkout tags/1.28.0-rc7 -b check_1_28
COMENTAR UN TAG
Consiste en incluir un mensaje con la etiqueta de la versión entregable. Abre el editor para incluir el mensaje de la DN (Delivery Note)git tag -a v-1.0
Para mostrar la información de un tag:
git show <tag_name>
COMPARAR TAGS
Se usa para ver las diferencias de código entre dos versiones entregablesgit diff <tag_1> <tag_2>
ETIQUETAR UN COMMIT ESPECÍFICO
Puede resultar útil a veces etiquetar un commit ya procesado en lugar del último commit.Nos puede servir también para comparar dos commits usando sus tags con git diff.
ACTUALIZAR TAGS
Si hemos etiquetado un commit equivocado, necesitamos asociar la etiqueta a otro commit.Se usa la opción -f (force) indicando el commit corrrecto.
git tag -a <tag_name> -f <commit-id>
Resolving Pull Request merge conflicts
https://github.com/AgileVentures/MetPlus_PETS/wiki/Resolving-Pull-Request-merge-conflictsReferencias
Página oficial. https://git-scm.com/doc
Guía sencilla de Git. https://rogerdudler.github.io/git-guide/index.es.html
Un montón de buenos tutoriales de Git. https://gist.github.com/jaseemabid/1321592
Tutorial de Git. https://www.vogella.com/tutorials/Git/article.html
0 comentarios:
Publicar un comentario
Gracias por participar en esta página.