Bueno... Git no se inventó para ser fácil. Lo inventó Linus Torvalds para su uso personal.
Los comandos no son oscuros. Son perversos. Torvalds dijo una vez que todos los comandos de git son solo shortcuts de git rebase. Lo dijo curado como raja y luego lo negó, pero de una manera elaborada es verdad. Podríamos decir que por ejemplo
> git rebase --onto staging --prune --aggresive --abbrev --filter-branch ...
En realidad es la forma canónica de escribir
> git gc
(La sentencia de arriba no tiene sentido, es un ejemplo extremo usando flags que se me ocurrieron ahora).
Git !== GitHub
Con respecto a GitHub, efectivamente no es lo mismo que git. De alguna manera es mucho más. Yo he invertido cientos de horas codeando para proyectos open source que alguna vez usé como librerías en mis desarrollos. Si encontraba un bug, una limitación o quería añadir algo, clomlnaba el proyecto, añadía mí contribución, creaba un pull request en el repo original, Profit. Fama y fortuna (en realidad con cueva te dan las gracias)
Cuando sigo el mismo flujo y el proyecto está alojado en bitbucket o gitlab... Lamentablemente le hago el quite como si fuera agua mineral. No le meto horas a proyectos en otros sistemas. Son una paja.
Servidor local vs PaaS
Es técnicamente posible mantener tu propio servidor de git. También es posible inventar tu propio algoritmo de cifrado. Posible y buena idea no guardan correlación. Dado que tú copia local es fiel.reflejo de todo.el proyecto en realidad ya tienes un "servidor" local. Si lo necesitas para compartir código entonces necesariamente sácalo de tu entorno local. Si lo necesitas para tener un plan de recuperación de desastres, sácalo de tu local. Sácalo de Chile y si es posible del sistema solar.
Y si lo pones en la nube, no gastes tiempo en resolver temas.de alojamiento, acl, autenticación, llaves,. tokens, Hooks, CI, y sobretodo para almacenar el porno, etc. Ya está resuelto en GitHub. No solo en GitHub, pero revisa el párrafo anterior.
git vs Dropbox/OneDrive/Google drive
Actualmente la mayoría de los discos en la nube permiten restore-to-point-in-time y una papelera infinita. El espacio ya no vale nada -_-
Sin embargo hay dos aspectos a considerar que marcan toda la diferencia. Git es un sistema de control.de.versiones. Sí, pero es más que eso. SVN es un Cvs a secas. Git está hecho para facilitar el merge entre ramas.
Si en google drive tengo un documento donde escribo A, luego B, luego C, no hay cómo quedarse con una versión que tenga solo A y C. Eso como ejemplo básico. Obviamente no hay cómo mantener un árbol de versiones en paralelo, pero si un proyecto necesita mantener 25 ramas entonces hay que refactorizar urgente.
Segundo, de nuevo en comparación con SVN o cualquier sistema que permita revertir, git no guarda copias. Guarda diferencias. En comparación el espacio utilizado por SVN es exponencialmente mayor.
Hora de la anécdota
Cuando trabajaba en una empresa que no voy a nombrar (pero es Celfin Capital y que tanto) el gerente de turno puso a uno de sus perritos falderos a hacer control de.gestion del software, si eso significa algo.
No me acuerdo cómo se llamaba el pelotudo, pero en mí memoria está almacenado bajo la categoría "guaton chupapico" (sic). Un día llegó GC y me dijo
- oye, estuve revisando y eres el desarrollador que tiene menos commits
- es posible. De hecho según mis cálculos tengo uno al día.
- no, es menos, son cinco por semana.
- debe ser porque no vengo sábados ni domingos. Pero si miras el texto de lo que pushheo, son squashs de varios commits
- no entendí nada pero es normal porque no estoy acá porque sepa sumar sino porque se la soplo al gerente. Pero te advierto, estás al debe.
De ahí en adelante cada vez que apretaba una tecla se venía commit y después de cada commit se venía push. Al final del semestre me felicitó.
Enviado desde mi HMA-L29 mediante Tapatalk
[/B][/B]
).
