Lectura
Destacados de esta lectura
diff --staged
branch --merged/--no-merged
SHA-1
Manual Bisect
Update submodule
core.autocrlf
Everyone knows that Word(tm) is the most horrific editor around; but, oddly, everyone uses it.
Con esta frase el Scott Chacon, autor de Pro Git, cofundador de GitHub y @chacon en twitter, empieza a explicar una característica especial de Git para explicarnos cómo revisar versiones de archivos binarios como los propios de Word.
Lectura
Este libro va de mostrarnos las bondades de este Sistema de Control de Versiones Distribuidos (DVCS).
Empecé con git hace ya un par de años, los principios no fueron fáciles. En muchos sitios se podían leer tutoriales y preguntas de ayuda pero para alguien sin experiencia previa en Sistemas de Control de Versiones todos esos recursos parecían hablar de un arte oscuro. Obviamente no podía ser así pues github/bitbucket tenían millones de usuarios y no puedo haber tantos cracks all around the world.
 |
Con la perspectiva que da el tiempo y la experiencia, ahora todos aquello recursos parecen muy asequibles, pero hay que vivirlo para contarlo.
El caso es que quería poner en orden mis conocimientos de git y que mejor que el libro de la referencia original para ello.
La elección del libro creo que ha sido todo un acierto, el libro está muy bien estructurado muy bien explicado y con muy buenos ejemplo, un combo en toda regla.
Me ha permitido asentar conceptos que usaba pero desconocía su funcionamiento. He comprendido conceptos que conocía de oídas pero no me había atrevido a usar. Sé que tengo un manual de referencia de Git en temas tan diferentes como git en server, herramientas de Git, customizar git, etc.
Destacados de esta lectura
Os voy a contar las cosas que me han llamado la atención de esta lectura, si volviera a leer el libro seguramente hubiera elegido otras y de ahí lo interesante de este libro. Por mucho que toques git seguro que descubres o redescubres un comando que necesitabas y no sabias/recordabas que existía.
diff --staged
Haciendo un diff puedes ver los cambios desde el working directory con el staging area.
Con un diff --staged puedes ver justamente la diferencia entre el staging area y el último commit.
Muchas veces tras meter unos cuantos archivos te gusta revisar los cambios para poner un comentario de commit bien descriptivo.
Muchas veces tras meter unos cuantos archivos te gusta revisar los cambios para poner un comentario de commit bien descriptivo.
branch --merged/--no-merged
Este comando te lista las ramas que han sido mergeadas/no mergeados en la rama de estado actual
SHA-1
en el libro se comenta que mucha se preocupa por el tema de que en su repositorio se de un colisión de hash entre dos commits. Aparte de explicar el funcionamiento cuando esto sucede(apenas habría cambios significativos en funcionamiento) esclarece las probabilidades de este hecho.
If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history(1 million Git Objects) and pushing it into one enormous Git repository, it would take 5 years until that repository of a single SHA-1 objects collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.
Pero bueno son probabilidades, habría que preguntar a Facebook por su hipermegarepo de 54GB
En Quora comentan que para resolver este problema sus ingenieros han decidido no usar Git y cambiar por Mercurial, pero desde luego es un caso extremo y habría que hacerselo mirar
^ ~
Estos caracteres tan esotéricos de git. Durante la lectura esclarecen su diferencia.
^ la referencia al padre del commit.
HEAD^ El commit padre del commit donde esta apuntando el cursor HEAD
HEAD^2 Hace referencia al segundo padre(cuando haces un merge un commit puede tener dos padres)
~ la referencia al primer padre
HEAD~ Equivalente a HEAD^ El primer padre del commit
HEAD~2 El primer padre del primer padre = El abuelo del commit (2 commits previos)
HEAD~3 === HEAD ^^^
Parece un poco lioso pero la aclaración, cuando se necesita, se hace bastante obvia.
Manual Bisect
Para detectar cuando se metió un bug en el código puede usarse un test automático, pero no siempre se puede automatizar esa comprobación y hay que hacerla a manivela.
Como funciona esta funcionalidad?
Le indicamos a git que vamos a buscar un error.
git bisect start
Le indicamos que el commit actual contiene el error.
git bisect bad
Le indicamos cuando el error no estaba presente(por ejemplo en la tag v1.0)
git bisect good v1.0
En este momento git se pondrá en el commit intermedio entre HEAD y v1.0
Comprobamos si existe el error, si funciona todo ok le avisamos a git
git bisect good
De esta forma e iteraivamente estamos haciendo una búsqueda binaria para encontrar la raíz del problema. Una vez encontrado ejecutamos lo siguiente para poner el cursor otra vez en el HEAD
git bisect reset
Update submodule
Esta anotación fue de hecho marcado porque justo un par de días antes de leerla me encontré con el problema que se comenta.
Actualizaba una dependencia a una versión concreta 2.4.6 y cuando me quería dar cuenta la dependencia volvía a la versión 2.4.5, era un comportamiento raro pero bueno al final descubrí que tras hacer el pull de un submodule tienes que actualizarlo pues git guarda el git de referencia de estos
git submodule update
core.autocrlf
En este caso se comenta una configuración. Lo interesante de aquí es que se explica muy claramente los problemas entre los OS Windos/Unix(Linux,Mac) con el tema de crlf. En sistemas windows el salto de línea se marca por el salto de carro(cr) y salto de línea(lf), mientras que en Unix es solamente el salto de línea(lf), es probable que en equipos donde haya gente mezclando sistemas pudiera haber problemas.
Git siendo multiplataforma se ha hecho cargo de este apartado. Al hacer push/pull se encarga de hacer los cambios oportunos para evitar este problema.
Git siendo multiplataforma se ha hecho cargo de este apartado. Al hacer push/pull se encarga de hacer los cambios oportunos para evitar este problema.
Justo ahora que tenemos tres muchachos de prácticas he podido ver en primera persona como git se encarga de realizar este proceso de forma prácticamente transparente y se agradece mucho.
No comments:
Post a Comment