Hace 8 años | Por arllutoquintumi a xkcd.com
Publicado hace 8 años por arllutoquintumi a xkcd.com

Viñeta que ilustra el desconocimiento sobre Git

Comentarios

D

#14 Le gusta el pedazo

D

#32 Iiiiivan

D

Mi experiencia tal cual.

xkill

#1 creó que falta una buena traducción de la documentación al castellano y un libro "git for dummies".

D

#10: Ayer puse esto en el nótame: http://git-man-page-generator.lokaltog.net/

PythonMan8

#1, #2, #etc

D

#12

Patxi_

#7 Lo de las ramas, subramas y demás son perfectas para un desarrollo tan complejo como el de un kernel.

Pues si no las necesitas, no las uses

El problema con las ramas es el que dice #8, que si las necesitas con svn sí que es una pesadilla.

D

#7 creo que después del sistema de revisiones pull requests de git no quiero otra cosa.

D

#17 Mercurial tiene prácticamente lo mismo. Just sayin', por si alguna vez te obligan a gastarlo. Que yo también prefiero Git, pero Mercurial siempre está ahí.

D

#50: Yo opté por TortoiseHg desde que ví el circo que es Git.
Mi tiempo lo pierdo en cosas productivas o improductivas, pero lo decido yo. Y si quiero hacer el tonto en la línea de comandos lo hago por voluntad no por sistema.

D

#7 Imagino que estes troleando, de lo contrario tu comentario es una estupidez, sin acritud

D

#7 "Cleanup has failed. Please run cleanup to solve it"

kesar

#23 tanto como llamarlo puta mierda... quizás vas tan sobrado que puedes programar tu algo mejor que subversion, te propongo el nombre, subcuñado.

D

#37 ¿Para qué, si ya hay herramientas mucho mejores?

perroloco

#37 El no dice que puede programarlo, el dice que puede usar uno mejor, a ver si ahora para criticar una herramienta hay que saber programar una mejor, no digas chorradas hombre.

kesar

#56 llamar puta mierda a algo no es una crítica muy constructiva que se diga, mas bien suena a desprestigiar el trabajo de un grupo de personas que habrán intentado hacer una herramienta, que muchos hemos usado por años. Podrás decir que es mejor o peor y dar motivos, pero llamar puta mierda a algo, no aporta nada.

perroloco

#60 Ya veo, ¿y no le puedes contestar eso en lugar de retarle a programar algo mejor?. Ni que hubiera insultado a la memoria de tus antepasados macho.

kesar

#71 entiendo que cuando se descalifica el trabajo de otras personas es porque uno cree que lo puede hacer mejor. También podría simplemente decir "vaya puta mierda de comentario"

No es que se insulte a mis antepasados, es que a veces se tiene la mala costumbre de descalificar/desprestigiar el trabajo de otros sin ningún motivo.

D

#75 Apuntar las versiones a lápiz en la caja con las tarjetas es una puta mierda.

¿Qué? ¿Que hace tiempo esa era la única forma de controlar las versiones de un programa? Me parece cojonudo. Hoy estamos a 2015, tenemos git, mercurial, y muchos más, y tanto la caja de las tarjetas, como el disquete de 3.5, como CVS y SVN, son (presente del indicativo del verbo ser) todos una puta mierda.

M

#23 El comando rebase no lo acabo de entender bien.

D

#49 un ejemplo es con una rama en local con muchos commits

M

#78 Si pero ¿Por qué es bueno hacer un rebase en vez de un pull y merge automatico que te sale?

D

#84 no es que sea mejor, es sólo para que las ramas del proyecto no parezcan el metro de Madrid.
Aquí lo explican muy bien:
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

delawen

#49 ¡¡Bienaventurados aquellos que no conocen el rebase!! Porque ellos no habrán metido tanto la pata

D

#49 Rebase explicado con un árbol: esto que va creciendo una rama, pillas un serrucho, la cortas, y la pegas en otra rama.

Lo más "complejo" de rebase es entender que si pillas el tronco (master), lo cortas y lo intentas pegar en una rama... te puede quedar una escultura moderna muy molona, pero un árbol bastante chungo.

Wakkatela

#46 #49 #82 #102

Creo que es perfecto si estás acostumbrado o tienes una necesidad, pero veo a muchos diseñadores con poca base de código intentando darle a la consola.
Me parece genial que aprendan, pero me parece raro que sólo lo hagan con Git.

Es más un dato curioso que un "ostia puta que mal están haciéndolo".

D

#23 Por no hablar de un proyecto para una sola persona. Git rules!

miguelpedregosa

#7 prueba a usar ramas con Subversion y luego me cuentas

ktzar

#7 Hablar sin tener ni pajolera idea, eso sí que mola... SVN es un infierno, seas uno, dos o cuatrocientos programadores.

Git no es difícil una vez entiendes la base, que tampoco es complicada.

f

#36 ¿dónde está ese infierno? Update, commit, merge si hay conflictos, y todo lo demás es hacer copias de directorios.

ktzar

#53 Tener dos ramas de trabajo cuando tu proyecto supera los 20.000 archivos es muy trabajoso. El poder hacer "rebase" para resolver conflictos es comodísimo y reduce la cantidad de grandes merges. Por otro lado, es tremendamente lento al tener que interactuar continuamente con el servidor, lo que hace que la integración continua sea más lenta.

La lentitud a la hora de crear tags y ramas hace que sea mucho más complicado separar un proyecto grande en diferentes repositorios, que se referencien unos a otros y "apunten" a una versión concreta.

Y por otro lado, el no poder trabajar offline es un desastre. Y podría seguir... En cambio Git no tiene ninguna desventaja.

f

#68 lo de las ramas no te entiendo... con subversion haces un "copy" del directorio del proyecto y ya tienes una rama, y como el copy es un mero link, es inmediato. Los tags es igual: subversion no distingue entre rama y tag, todo son copias. http://stackoverflow.com/questions/25207108/cost-of-branching-svn-vs-git

El rebase en subversion es un mero update, ya que todo el mundo trabaja contra el mismo repositorio. Te pueden salir conflictos en aquellos ficheros que hayas tocado y no subido, como con el rebase de git, eso te pasa en cualquier sistema. De todas formas, donde no gusta encontrar conflictos, subversion permite hacer lock, cosa que en git creo que no puedes hacer. Eso ya va en gustos, he trabajado de las dos formas.

Lo del offline de acuerdo, pero en general eso no es un problema en la mayoría de las empresas porque la gente está en un ordenador de la oficina conectado al servidor de la oficina. Pero sí, es una ventaja de git, sin duda.

Yo he trabajado con los dos, y el 99% de las veces he funcionado igual con subversion. En cambio el rollo stage/unstage del git me cansa, la verdad.

delawen

#81 Crear una nueva rama en subversion es fácil. Pero ahora trabaja un par de meses por separado en ambas ramas. Luego intenta unificarlas de nuevo en una única rama. Si has modificado los mismos ficheros a un lado y a otro, ya puedes llorar mientras esperas que subversion haga el merge bien.

Git resuelve ese tipo de cosas de manera mucho más transparente.

Y me dirás, ¿pero qué clase de engendro del mal haría algo así, separar ramas, modificarlas a lo loco y luego querer unificarlas otra vez? Te contesto: proyectos donde necesitas una rama estable a la que ir añadiendo sólo los cambios estables, pero que hay cambios que tardarás meses en poder terminar completamente y no quieres meterlo a "trocitos" para no romper la rama estable. O te dedicas perder el tiempo haciendo merges continuamente para que tu rama "inestable" esté actualizada o te dedicas a perder el tiempo haciendo un merge enorme al final.

Por no contar con la problemática de qué pasa si estás manteniendo versiones antiguas de un mismo software. En git, puedes meter una actualización de seguridad (por ejemplo) en la rama más antigua y pasarla limpiamente hacia "delante" hacia todas las versiones más modernas de forma transparente para ti en un solo comando. En subversion tienes que hacer parches, que podrán o no tener sentido en todas las ramas/versiones a las que lo quieres aplicar. Al final, acabas haciendo una y otra vez el mismo cambio a mano en cada versión.

Trabajar con subversion es como trabajar en una única rama de git. O sea: un dolor de cabeza si tienes equipos trabajando de forma simultánea en features diferentes pero sobre los mismos ficheros.

D

#93: ¿pero qué clase de engendro del mal haría algo así, separar ramas

D

#93 "un dolor de cabeza si tienes equipos trabajando de forma simultánea en features diferentes pero sobre los mismos ficheros."

O incluso si eres una sola persona trabajando en features diferentes de forma simultánea. Desde que he descubierto git, tiro de ramas prácticamente para todo.

f

#7 totalmente de acuerdo... para un grupo de gente que trabaja en la misma sede, subversion y tortoise te solventan la papela estupendamente.

cosmonauta

#7 subversión y Git son, a grandes rasgos, lo mismo. El problema no es el cvs que uses, sino la gestión de las ramas y en eso nos complicamos la vida nosotros, independientemente del sistema usado.

En realidad, muchas veces no es necesario hacer ramas. Otras, simplemente hay que mantener 2 o 3.

La locura viene cuando algún psicópata se lia a crear ramas como un loco.

Pablosky

#7 ni de coña, los merges en SVN dan asco comparados con los de Git.

garnok

#13 ¿barrapunto? eso ya no es lo que era

GeoX

#26 ¡Pero sigue usando Debian!

D

Acaso somos en meneame un puto nido de programadores? No me esperaba muchos comentarios de gente entendiendo la viñeta

GeoX

#5 Debes ser nuevo. ¿Has oído hablar de barrapunto?

D

#13 Sí, claro. Sin embargo, como programador .net, no está entre mis sitios web más visitados. Estoy más en el lado oscuro.

D

#44 Porno de embarazadas?

D

#5 Yo no la entiendo pero la comentó, faltaría más. Ni que esto fuera Forocoches, la web de los intelectuales.

D

#5: En MNM hay infinidad de expertos en todo. Igual que en cualquier bar.

geralt_

#5 Menéame es cuna de la Todología Universal, sabemos de todo a nivel experto.

D

#5 y mucho cuñaomatico

D

#5 De programar ni papa, pero compilar lo de otros por un tubo.

HyperBlad

Qué git ni qué git. Un zip con la carpeta del proyecto y fecha en el nombre. Hipsters, que sois unos hipsters.

D

#64: En de verdad que sí. Lo que hacen por llamar la atención. Luego no usan Git más que para compartir recetas de muesli y algas kelp.

u_1cualquiera

He usado cvs, svn, bitkeeper y Git.
En todos saco las mismas conclusiones
Da igual lo poderosa que sea la herramienta, la estupidez humana la supera
Lo importante es s tener un juego de tests que todo el mundo pruebe antes de Git push.

S

#87 Gracias por el enlace, le echaré un vistazo a ver si me entero por fin.

hamijo

Lo mismo digo. Pagaría una cantidad aceptable por aprender bien como se utiliza de manera correcta y sin miedos a reventar el proyecto

He leído muchos tutoriales y o bien llego a la conclusión de que soy tonto por no entenderlo bien o liarse cuando se trabaja con varias ramas es algo normal lol

D

#2 Las ramas y versiones son algo que o eres muy bueno imaginándotelas, o necesitas una GUI que te dibuje las relaciones entre ellas... y aún así a veces hay que recurrir a papel y lápiz, o un editor de diagramas como por ejemplo yEd, para terminar de aclarar algún que otro lío. Y eso es aplicable tanto a git, como a cualquier otro sistema de control de versiones. Por suerte hay varias GUIs disponibles para git que lo hacen todo mucho más fácil.

Posiblemente lo único que haya que recordar en git, es que los nombres de las ramas se refieren a la punta, no a la base de cada una.

D

#2 Si alguien te da un curso barato, comparte. A mí también me interesa lol

D

#29 Jodo con la instructora Caroline Buckey...

f

#2 Totalmente de acuerdo... un buen curso sería genial.
Para el día a día, a mí este artículo me sirvió de ayuda: http://sergioviteri.com/2010/06/04/un-workflow-sencillo-con-git/
Y luego, siempre a mano: http://git-scm.com/book/en/v2

gungable

#2 Precisamente ayer descubrí esto por reddit : https://github.com/blog/2083-start-learning-git-and-github-today-with-self-paced-training . Está orientado a GitHub, pero aun así tienes todas las bases y filosofía de Git resumidas en dos horitas.

llorencs

Yo me quedo con CVS lol.

llorencs

#59 Es el mejor sistema

alexwing

#59 las fechas YYYY-MM-DD por lo menos hombre.

D

#73 Eso es muy friki, demasiado complejo.

D

#59


mkdir proyecto-N

ln -s proyecto-N release

LN está para algo. Para eso precisamente.

D

#83 Otro que viene con complejidades.

jaitrum

#41 Todavía tengo pesadillas con los merges en CVS, o con una simple refactorización y cambios de nombres... ¡¡¡el horror... el horror!!!!!

n

Pues no será por buena documentación sobre como usarlo, Git es de los proyectos con más documentación que he visto. Al principio cuesta un poco pero cuando le cojes el tranquillo te das cuenta de lo potente que es.

MEV

Con Git pasa como con Vim o con un lenguaje de programación mismo: no puedes esperar aprender a usarlo bien de un día para otro.

Se empieza usando lo básico y consultando los comandos, y poco a poco conforme trabajas con ellos vas ampliando tus conocimientos de la herramienta y aplicando nuevas cosas.

En mi caso me tiré meses trabajando sin entender un pijo de la mitad de las cosas, los rebases me sonaban a chino y de vez en cuando hacía alguna liada en local.
Tras numerosos desastres/guarradas por parte de algunos compañeros, un día un grupo de compis de curro nos pusimos a discutir, investigar y establecimos un workflow con rebases y squash de commits previo al mergeo de las ramas. Desde entonces hacíamos las cosas mucho mejor, y como lo usábamos a menudo entendíamos cómo funcionaba y mejoramos nuestros conocimientos de git.
Otros compis de curro se negaron a sumarse a "hacer las cosas bien" con git, y eran precisamente los que la liaban, lo que provocaba roces porque da un poco de asco intentar hacer las cosas bien y que el de al lado se pase por el forro de los cojones las guías de estilo porque no quiere dedicarle ni un día a actualizarse.
Al final los que mejoramos usando git hemos acabado en empresas donde el nivel es mucho más alto, y donde lo de usar bien git ni se discute. Los otros siguen en su mundo.

Y vamos, aún me quedan muchas cosas por controlar/entender, que de vez en cuando me veo en un "detached head" y cagándome en todo. Pero poco a poco, como hasta ahora.

tunic

Unas ayudita para el asunto de manejo de ramas que suele ser lo que más desconcierta:
http://pcottle.github.io/learnGitBranching/

Hay que pensar es que git organiza los commits en un gran árbol y las etiquetas y las ramas son simplemente apuntadores a un commit concreto.

Y sin miedo a romper nada, siempre puedes tirar de git reflow para reflog cuando la lías gorda para recuperar cosas.

D

A lo mejor es pq no soy un friki de la consola,ni de estudiarme un libro para gestionar el codigo, pero me sorprende que nadie haya mencionado gitextensions . Adios peleas con git.

Wakkatela

#21 O Sourcetree en caso de Mac. Nunca entenderé a esa peña que tiene que usar la consola si o si, escribir 3 líneas de comando en vez de pulsar un botón en una UI.

averageUser

#40 Sourcetree en Windows es un nido de bugs y un vampiro de recursos, para suicidarse.

D

#40 En la consola puedes personalizar comandos y atajos. Yo trabajo mucho más rápido en la terminal que con una GUI, al menos con git.

cuatroD2

#40 Lo que dice #48 más que te permite trabajar en remoto fácilmente (vía ssh) y casi no consume recursos. Si vas a usar una herramienta a diario tirar de consola puede ser mucho mejor; si solo la vas a usar de pascuas a ramos la UI es más fácil.

D

#40 la respuesta es que muchos trabajamos desde un cliente tmux con un servidor por ssh y editamos en vim. Escribir un par de líneas más en la terminal es lo más fácil.

D

#22 Depende de la cantidad de gente que utilice el mismo repositorio. Cuando varias personas hacen cambios, SVN se lía con mucha facilidad y entras de cabeza en el merge hell. Ahí ya dejas de verle la sencillez.

a

Como casi siempre, el problema no es la herramienta, los que tienen problemas con el control de versiones no es porque no entiendan git, es porqué no entienden como gestionar las versiones de un proyecto y porqué hacen lo que están haciendo. Lo fundamental no es si uso git, mercurial o svn, lo fundamental es si hago main line development, hago feature branching etc,etc y porqué hago esto en función del tipo de desarrollo y de las necesidades que tengo. No es lo mismo hacer una librería o un producto del que tengo que soportar N versiones vivas al mismo tiempo que desarrollar un sistema en el que sólo tengo viva la ultima versión, tengo que pensar en el balance entre tener ramas y hacer mis integraciones menos frecuentes o tener una única rama y integrar de forma constante, tengo que pensar si tengo o no una estrategia de despliegue continuo y como afecta la politica de ramas a esa estrategia etc,etc.

Luego, cuando uno tiene los conceptos claros y sabe lo que hace y con que objetivos, se trata de elegir la herramienta que mejor implemente las practicas que quiero seguir. Mientras la gente insista en hacer las cosas al revés, elegir primero una herramienta y luego adaptar sus prácticas a lo que permita la herramienta, pues mal asunto, luego nos quejamos de la herramienta porque no hace milagros.

Zootropo

La traduje ayer al español, para quien lo prefiera:

http://mundogeek.net/archivos/2015/10/31/git-es-sencillo/

Marinmenyo

Nosotros estamos trabajando en una asignatura de la universidad, un grupo de 26 personas sobre un mismo proyecto. Lo mejor es una GUI para ver el orden de las ramas y la relacion entre ellas y la consola para realizar cualquier operación.
La verdad, llevo un tiempo usando Git por mi cuenta o como mucho entre dos y ahora, trabajando entre tantos, es cuando estoy empezando a aprender a usarlo.

D

Lo mismo se puede meter en .gitconfig como en un alias.

git log --graph --pretty=format:'%C(bold white)%h%Creset -%C(bold yellow)%d%Creset %s %Cgreen(%ci) %C(bold blue)%Creset' --abbrev-commit --branches

Será humor, pero merece voto de errónea. Ninguna necesidad de guardar el proyecto en otro lugar.

git reset --hard y git reflog, esos grandes desconocidos.

No hace falta memorizar ningún comando. El que lo usa todos los días los sabe y punto. Luego los amateurs ya tal...

d

Echad un ojo a git flow. Añade una capa por encima que permite seguir un Orden. Aunque si eres un marrano puedes seguir guarreando en el master.
Yo tengo un master resolviendo conflictos de mi compañeros y no soy asistente social http://danielkummer.github.io/git-flow-cheatsheet/

Er_Pepe

Dropbox es una de las opciones más utilizadas como sistema de control de versiones para proyectos pequeños

o

#89 Para proyectos pequeños realizados por becarios.

Dropbox para control de código? un profesional no lo haría.

Sofrito

Genial

ktzar

Para entender Git un buen texto es "The Git parable" http://tom.preston-werner.com/2009/05/19/the-git-parable.html

Largo, pero muy educativo e ilustrativo.

Relator

Me quedo con Subversion, mucho más sencillo.

Relator

#18 Me refiero a curvas de aprendizaje y solvencia ante problemas sencillos. Pero sí, no niego en absoluto las bondades de GIT

D

#15 SVN no es mejor ni para proyectos de andar por casa. Con git, con que sepas hacer git add . git commit y git push vas sobrado para trabajar en tus proyectos personales, mantenerlos en GitHub (o BitBucket o donde quieras) y vas a tener un control de versiones más férreo.

D

#15 En realidad, si dices que "Subversion es mucho más sencillo", es porque no has necesitado nunca hacer otra cosa que no sea "svn diff" y "svn commit".

Y eso lo puedes hacer exactamente igual con Git. Git se complicará lo que tú quieras que se complique.

m

Acá cometo karmacidio
http://bazaar.canonical.com/en/

M
freelancer

#67 Yo también

Zeioth

Se que no es nada 1337, pero la GUI de git-cola va genial para gestionar ramas de forma visual. En general es muy agradecido no tener que ir a google cada vez que necesitas un comando de los que usas de higos a brevas como los stash o los cherry pick.

Sofrito

Pienso que lo mejor de Git no es Git. Es Github. De hecho, Git no es "windows friendly". Fue concebido desde la línea de comandos y no creo que exista una interfaz que realmente exprima todo su potencial. Y muchos usuarios son reticentes a tener una ventana de comandos abierta. Sobre todo los usuarios que vienen del infame Windows.

S

Estoy aprendiendo a programar y me estoy dando cuenta de que necesito un sistema de control de versiones, ya la he cagado un par de veces por ir haciéndolo sin él. Dado que no soy informático, querría algo lo más simple posible para ir trabajando desde distintos ordenadores, ¿algún consejo de cuál debería usar?.

D

#65 git. Para no complicarte y para empezar puedes ponerlo todo en una única rama (la master). Luego cuando vayas cogiendo soltura ya te meterás con otras características.

Utilizarlo es muy sencillo:
- git add path --> para añadir ficheros al repo
- git commit -am "descripcion de los cambios" --> para añadir todos los cambios al commit y escribir qué has cambiado
- git push --> para subir los cambios a la página donde almacenes el repo

- Si trabajas en equipo ya tienes que hacer un pull antes de cualquier commit. Básicamente por si alguien ha hecho un cambio desde la última vez que actualizaster tu copia local. Si no lo haces y ha habido algún cambio entonces el repo creará una nueva rama, que tendrás que unir a la máster con git merge
- Si quieres disfrutar de git sin tener que crear el repo en una página y bajártelo entones simplemente escribe git init en el directorio raíz y empieza a utilizarlo.

D

#65: Yo te recomiendo TortoiseHg. Usa Mercurial, no Git. Aunque Git también tiene sus guis como GitHub o SourceTree.
Con el tiempo que ahorras te puedes echar una siesta.

Kaizen

¿Nadie ha probado el GitHub Desktop? https://desktop.github.com/

eN4N0

#39 Yo me acostumbre tantisimo a que me haga un stash automaticamente cuando cambio de rama y me lo vuelva a recuperar cuando vuelvo que interiorize esa feature como propia de git y ahora me cuesta pasar a otros GUI mas potentes.

averageUser

Siempre podéis utilizarlo con Sourcetree para terminar de decidiros y pegaros finalmente un tiro.

o

#c-42" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2502976/order/42">#42 SourceTree es la caña, da asco porque es C# y no pueden portarlo a Linux, pero mola.

chumifu

Panda de freaks, me voy a Reddit!

D

no es complicado. Eso si, mucho ojo con los automerges

A

Yo tiro de tortoiseGit y me sirve perfectamente

1 2