Git, el gestor de código fuente de código abierto ha alcanzado su versión 2.5 que incluye dos nuevas características interesantes: git worktree, un subcomando para trabajar con múltiples directorios de trabajo dentro del mismo proyecto, y varias mejoras para trabajar con flujos de trabajo triangulares, además de las correspondientes mejoras en el rendimiento.
#4:
#3 Se supone que git worktree es para trabajar simultáneamente en varias cosas en el mismo proyecto sin tener que cambiar de rama para cada una de ellas. Sería como tener varias ramas del mismo proyecto desplegadas en diferentes directorios (en el ejemplo lo explica bastante bien: estás trabajando en algo, llega otra cosa más urgente y, en lugar de guardarlo —commit o stash— y ponerte con lo nuevo, lo dejas ahí, haces un worktree en otro directorio y trabajas en él).
Respecto a que es una herramienta simple… pues yo creo que no. Git es complejo y complicado. Pero toda la potencia que da suple con creces toda su complejidad. Y útil, vaya si es útil. Git es increíble.
#8:
#7 no, rsync solo copia ficheros y actualiza solo los que han cambiado. No tiene nada que ver.
Git te da el poder de viajar atrás en el tiempo (y otros similares). De traer un fichero de una versión antigua al presente, modificarlo y continuar trabajando.
O ir a la versión 1.0 de tu proyecto, que tiene más de 2 años por ejemplo, sin que pierdas ningun dato. Y cosas asi.
#41:
Muy útil el tema del worktree, es muy tipico el caso de uso de estar trabajando en una feature nueva y que te venga un bug urgente y tienes que andar haciendo stash o algún commit guarrero para cambiar el directorio de trabajo a una nueva rama y hacer un hotfix. De esta forma puedes mantener dos directorios separados en el mismo repo apuntando a cada rama y simplifica los cambios de contexto (que antes también lo podías hacer, pero clonando en varios dir el repositorio que es más coñazo).
Ya puestos podían añadir facilidades para otros flujos de trabajo, como el típico git-flow.
#39:
#6#5 Y no sólo eso, también guarda un historial del desarrollo de software para saber quién ha hecho qué y cuándo (que se suele usar para echar las culpas . De hecho hay un comando, git blame, que se usa para eso; no para echar las cumplas, pero sí para ver quién ha hecho qué).
#3:
Es cierto que git no ofrece ninguna ayuda específica para trabajar con varios remotes, más allá de tener esa funcionalidad maravillosa. Yo suelo trabajar con 8 o 10 remotes (no a la vez, normalmente sólo el mencionado esquema triangular o como mucho 3 remotes).
La verdad es que todavía no veo cómo sacar partido a git worktree, pero todo llegará.
Git es de esas herramientas maravillosas por lo simple y por lo útil.
#7 no, rsync solo copia ficheros y actualiza solo los que han cambiado. No tiene nada que ver.
Git te da el poder de viajar atrás en el tiempo (y otros similares). De traer un fichero de una versión antigua al presente, modificarlo y continuar trabajando.
O ir a la versión 1.0 de tu proyecto, que tiene más de 2 años por ejemplo, sin que pierdas ningun dato. Y cosas asi.
#14 Probablemente si no sepas lo que es Git, no lo necesites. Git es una herramienta imprescindible para desarrolladores. No sólo porque te permite tener una copia de todas tus versiones de forma instantánea, Git es mucho más. Git permite trabajar en cosas paralelas sin que una interfiera en la otra.
Por ejemplo, si tienes una web de coches y quieres crear un sistema de usuarios, eso te puede llevar un tiempo y, probablemente hayan arreglos q tengas que hacer que son más pequeños. Git te permite crear ramas y luego juntarlas una vez hayas acabado para que una cosa no moleste la otra. Eso con Dropbox no es posible.
#37 A mi tambien me parece altamente complejo y utilizo SVN creo que a nivel alto. Varias ramas, merge, etc
#26 Eso ya lo hago con SVN, una rama por cada evolutivo, el problema es que hay que hacer merge cada cierto tiempo para no desactualizar las ramas porque sino reintegrar las ramas es un problemon.
#46 Te recomendaria entonces empezar a hacer algun proyecto independiente usando git para familiarizarte con el... Una vez que controles git, prueba a pasar alguno de tus proyectos menos importantes de SVN a git, y acaba mudando todos...
Yo en el trabajo uso SVN, en casa, GIT
#26 Tampoco es eso. Mucha gente hace control de versiones "de andar por casa", ya sea haciéndose copias de la carpeta de trabajo poniendo la fecha en el nombre, o metiéndola en un dropbox. Este gente puede que no sepa lo que es un Git, pero si se lo explicas muy probablemente lo apreciarán, y mucho.
Es cierto que git no ofrece ninguna ayuda específica para trabajar con varios remotes, más allá de tener esa funcionalidad maravillosa. Yo suelo trabajar con 8 o 10 remotes (no a la vez, normalmente sólo el mencionado esquema triangular o como mucho 3 remotes).
La verdad es que todavía no veo cómo sacar partido a git worktree, pero todo llegará.
Git es de esas herramientas maravillosas por lo simple y por lo útil.
#3 Se supone que git worktree es para trabajar simultáneamente en varias cosas en el mismo proyecto sin tener que cambiar de rama para cada una de ellas. Sería como tener varias ramas del mismo proyecto desplegadas en diferentes directorios (en el ejemplo lo explica bastante bien: estás trabajando en algo, llega otra cosa más urgente y, en lugar de guardarlo —commit o stash— y ponerte con lo nuevo, lo dejas ahí, haces un worktree en otro directorio y trabajas en él).
Respecto a que es una herramienta simple… pues yo creo que no. Git es complejo y complicado. Pero toda la potencia que da suple con creces toda su complejidad. Y útil, vaya si es útil. Git es increíble.
#48 ¿Rápido Subversion para hacer un branch? Si se hace una copia del repositorio entero...
Quizá si está trabajando con un repo de 10 ficheros vaya bien, pero prueba de hacer lo mismo con un proyecto grande, que con subversion implica unos cuantos minutos y mucho runrún de disco, mientras que en git es instantáneo.
No digo que sea el sistema más rápido. Posiblemente lo sea más el git o, al menos, tenga facilidades para trabajar con distintas ramas que no tiene el subversion. Digo que por muy grande que sea el directorio a copiar, el tiempo de crear la rama con Subversion es constante y muy bajo.
#3 totalmente de acuerdo con #10#16 y #51 git para nada es simple. Trabajar en un proyecto con 3 versiones diferentes que comparten la mayoria del codigo no es para nada simple.
#61 Ya se sabe, que git va cambiando su complejidad en función de los años que lo lleves usando.
Supongo que también les podrías preguntar por cómo tienen el ojete de dado de sí, es un criterio equivalente.
Git, desde el punto de vista del usuario es una reputa mierda pinchada en un palo. Otra cosa es que eso a los frikis sin vida les encante para presumir de son capaces de traspasar capas de ofuscación y comandos crípticos, muy típico precisamente de los que empiezan y todavía no se cansaron de perder el tiempo aprendiendo a pasar por el aro.
#63 Teniendo en cuenta que git trae una GUI de serie, que te enseña todo con dibujitos, y que la CLI está perfectamente ordenada y documentada... voy a querer pensar que ni te has molestado en mirarlo.
#66 Claro, claro, no es que tengas un problema psicológico de inseguridad con las herramientas que usas y que no admiten crítica ni mácula ninguna (que ya manda huevos), es que no me he molestado en mirar una herramienta con la que trabajo a diario. Uso git gui a diario y de vez en cuando con CLI, no vas a ahora a enseñarme a mí lo malo y bueno que tiene git.
#71 Ves... quería pensar que simplemente desconocías git, pero visto lo fácil que saltas con los insultos voy a tener que pensar otra cosa. Pos bueno, pos vale.
#3 bueno bueno, lo de simple no eh! Para nada es simple, es muy facil meter la pata, y tiene, precisamente, infinidad de maneras de hacer la misma operación.
Eso hace que la gente se lie que da gusto. Por ahi lo tildan como un "framework para diseñar flujos de trabajo" jaja
Muy útil el tema del worktree, es muy tipico el caso de uso de estar trabajando en una feature nueva y que te venga un bug urgente y tienes que andar haciendo stash o algún commit guarrero para cambiar el directorio de trabajo a una nueva rama y hacer un hotfix. De esta forma puedes mantener dos directorios separados en el mismo repo apuntando a cada rama y simplifica los cambios de contexto (que antes también lo podías hacer, pero clonando en varios dir el repositorio que es más coñazo).
Ya puestos podían añadir facilidades para otros flujos de trabajo, como el típico git-flow.
#41 Para git-flow existen extensiones desde hace tiempo que facilitan su uso: https://github.com/petervanderdoes/gitflow Si usas Linux es muy probable que tengas paquetes en la propia distribución, las más conocidas los tienen.
#77 Si a modo de extensiones, incluso en herramientas como SourceTree tienes soporte integrado también. Simplemente decía que se podían integrar como parte del core de git para simplificar y extender aún más su uso.
#28#21#17 etc: a portada llega lo que la gente vota. No todo va a ser noticias sobre corrupción del PP y sobre el león Cecil, que cansinos sois, por favor.
#49 Y al gobierno también llega lo que la gente vota . En mi opinión es algo muy específico y carece de interés general. Pero vamos Rajoy también carece de interés general y ahí está, eso sí, seguiré quejándome así que si te cansa ajoyagua.
#23#31 No me malinterpretéis, no tengo nada en contra de que noticias sobre informática lleguen a portada, pero si las características de la nueva versión de Git son relevantes, también lo pueden ser las de la nueva versión de Photoshop, Lightroom, Notepad++, AutoCAD, Google Chrome y así un largo etc...
#34 Eso es discutible. GIT está encabezando una revolución en el desarrollo, hasta el punto de que Github le está quitando protagonismo a Sourceforge, por ejemplo. Cada vez más desarrolladores se están animando a usarlo y a compartir su código con licencia GPL u OpenSource.
En cambio, el software cerrado seguirá siéndolo y cada vez más restrictivo.
No soy desarrollador, pero le veo muchas ventajas a GIT frente a los anteriores controles de versiones como CVS o SVN. Ójala supiese manejarlo mejor.
#34 Todo el que trabaja con datos, trabaja con versiones de documentos; no todo el que trabaja con datos, trabaja con Photoshop (o cualquier otro programa en concreto).
Si te fijas bien, cuando salen funcionalidades nuevas de Chrome, Firefox, o parecidos, también llegan las noticias a portada, por aquello de que también hay mucha gente que los usa.
#34 Yo tampoco entiendo muy bien el criterio la verdad. Hace poco mandé una noticia comentando que WINE va a soportar DX11 y cayó en saco roto. Los caminos de MNM son inescrutables.
Tengo la teoría de que el 95% de los usuarios de Git lo utilizan sin saber muy bien lo que están haciendo.
Sí, Git es muy potente, y muy útil, y todo lo que queráis; pero le falta una capa de abstracción para poder utilizarlo sin tener que conocer sus tripas.
Referencia: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/ [...] you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it. [...] It’s understandable that an advanced user might need to know a little about how features are implemented, to grasp subtleties about various commands. But even beginners are quickly confronted with hideous internal details.
#52 Ciertamente git puede resultar un poco arido, y si no tienes muy claro lo que haces cagarla es realmente fácil. En este sentido y sobre todo para gente que empieza un UI tipo SourceTree ayuda bastante a visualizar conceptos y actúa un poco a modo de esa capa de abstracción.
De todos modos el problema principal cuando se usa un CVS no es tanto el no conocer la herramienta como el no tener una politica adecuada de gestion de versiones, por ejemplo tener claro si haces feature-branching con un branch de desarrollo y otro de producción en el mismo repo (modelo git-flow), si haces un desarrollo con un repo central y otro por desarrollador y luego envías cambios con pull request (modelo más tipico en el open-source), si eres un hombre y haces main-line development y no usas ramas en general. Lo importante es entender que politica usas en tu proyecto y porque para luego mapear esa politica con los comandos y conceptos concretos de la herramienta que uses (git, mercurial, svn...), en mi experiencia lo que he visto mucho es que se usan los sitemas de control de versiones sin tener un politica definida y sin entender muy bien que están haciendo, entonces es cuando vienen los problemas.
#52 Comparte ese problema con Subversion.
Desde el eclipse, SVN es excelente, pero por línea de comandos, te querés matar.
Yo lo usé así durante muchos años, pero cualquier cosa difícil se complica bastante, por ejemplo un merge.
Con Git me costó mucho más la primera vez que hice push, pero es mucho más coherente como herramienta, tiene un modelo más fácil de entender. Te podés defender con pocos comandos, y luego ir aprendiendo cada detalle.
Por el lado de la abstracción, puede ser un arma de doble filo. Git te permite hacer cosas bastante sofisticadas, trabajando con árboles. No hay abstracciones fáciles para este, que es un problema difícil. Se puede abstraer algún proceso en particular, tipo git flow, o github flow, pero no parece buena idea para toda la herramienta.
#59 , he trabajado con ambos (Subversion y Git), y la curva de aprendizaje no tiene nada que ver; además, la terminología es muy confusa y muy poco coherente en Git.
Quiero decir, técnicamente puede ser muy bueno, pero cuesta mucho entender cómo funciona; y te apuesto a que mucha gente lo usa sin tener muy claro lo que está haciendo.
#52 Más bien que mucha gente usa Git exactamente igual que como usaba subversion: git commit para cambios, git push para enviarlo "para arriba", y git pull para bajar la última versión. Para eso, podrían quedarse en subversion.
Ahora bien, llegará el día en que querrán/necesitarán hacer algo complicado, y al estar en Git lo podrán hacer. Y entonces lo cogerán el gustillo, y poco a poco irán viendo todo lo que puede hacer Git por ellos más allá del subconjunto de "funcionalidades subversion".
#30 si alguno no lo conocia y lo conoce grcias a esto tal vez aprendan como la mayoria de profesionales consiguen no suicidarse a la hora de hacer control de versiones en sus proyectos por ejemplo. Es didactico y casi para toda la familia
pd: yo lo uso, pero a nivel wannabe, push, commits, merges, clone y poco mas con mi cara de: q clase de magia negra es esta
¿Pero lo de los workdir no estaba ya? Había un comando en la documentación que te permitía hacerlo. Había que copiarlo y ponerle el bit de ejecutable...
#6#5 Y no sólo eso, también guarda un historial del desarrollo de software para saber quién ha hecho qué y cuándo (que se suele usar para echar las culpas . De hecho hay un comando, git blame, que se usa para eso; no para echar las cumplas, pero sí para ver quién ha hecho qué).
#30 Yo soy informático, y sinceramente no me parece que esto tenga relevancia para el común de los mortales. Especialmente porque a la mayoría de gente les hablas de cualquier cosa más complicada que un chupete y se les queda cara de poker.
Si esto ha llegado a portada, es que a la gente le interesa lo suficiente como para menearlo. Y si a suficiente gente le interesa como para llevarlo a portada, sospecho que los que lo ven irrelevante son bastante menos del 99%.
Por cierto, todos los que piensan que git es "irrelevante" para la mayoria de los usuarios, deverian de saber que gallir usa git para administrar el codigo de meneame
#73 Sigue siendo irrelevante para la mayoría de usuarios de menéame, de la misma forma que muchas casas tienen ventanas de aluminio de rotura de puente térmico y no salen noticias al respecto o no te enteras de las novedades en la maquinaria de producción de motores de coches.
#29 Supongo que si hay un lobbie muy grande en MNM de informáticos, cualquier noticia especializada en el sector llegará a portada, aunque el 99% de los meneantes no tengan ni idea, ni les importe.
Comentarios
...
#7 no, rsync solo copia ficheros y actualiza solo los que han cambiado. No tiene nada que ver.
Git te da el poder de viajar atrás en el tiempo (y otros similares). De traer un fichero de una versión antigua al presente, modificarlo y continuar trabajando.
O ir a la versión 1.0 de tu proyecto, que tiene más de 2 años por ejemplo, sin que pierdas ningun dato. Y cosas asi.
#8 Yo suelo usar dropbox para explicarlo. También tiene "control de versiones" y es bastante fácil de entender.
#8 #7 Creo que habría que mencionar el poder trabajar multitud de personas concurrentemente sobre el mismo proyecto.
#13 Si, es que ya sabes que git es un universo paralelo lleno de movidas
#14 Creo que es la mejor definición que he oido nunca.
#14 Probablemente si no sepas lo que es Git, no lo necesites. Git es una herramienta imprescindible para desarrolladores. No sólo porque te permite tener una copia de todas tus versiones de forma instantánea, Git es mucho más. Git permite trabajar en cosas paralelas sin que una interfiera en la otra.
Por ejemplo, si tienes una web de coches y quieres crear un sistema de usuarios, eso te puede llevar un tiempo y, probablemente hayan arreglos q tengas que hacer que son más pequeños. Git te permite crear ramas y luego juntarlas una vez hayas acabado para que una cosa no moleste la otra. Eso con Dropbox no es posible.
#6 Pruebalo en 15 min https://try.github.io/
#37 A mi tambien me parece altamente complejo y utilizo SVN creo que a nivel alto. Varias ramas, merge, etc
#26 Eso ya lo hago con SVN, una rama por cada evolutivo, el problema es que hay que hacer merge cada cierto tiempo para no desactualizar las ramas porque sino reintegrar las ramas es un problemon.
Y que conste que quiero pasarme a Git ya
#46 Te recomendaria entonces empezar a hacer algun proyecto independiente usando git para familiarizarte con el... Una vez que controles git, prueba a pasar alguno de tus proyectos menos importantes de SVN a git, y acaba mudando todos...
Yo en el trabajo uso SVN, en casa, GIT
#26 Tampoco es eso. Mucha gente hace control de versiones "de andar por casa", ya sea haciéndose copias de la carpeta de trabajo poniendo la fecha en el nombre, o metiéndola en un dropbox. Este gente puede que no sepa lo que es un Git, pero si se lo explicas muy probablemente lo apreciarán, y mucho.
#13 Exacto. Es muy útil para saber quien y cuando LA HA CAGADO, para ir a su mesa y darle una paliza
¿Para cuándo soporte psiquiátrico?
#9 Para eso está stackoverflow.
#9: Desde que vi Git me quedó claro que lo que necesitaba era TortoiseHg.
Es cierto que git no ofrece ninguna ayuda específica para trabajar con varios remotes, más allá de tener esa funcionalidad maravillosa. Yo suelo trabajar con 8 o 10 remotes (no a la vez, normalmente sólo el mencionado esquema triangular o como mucho 3 remotes).
La verdad es que todavía no veo cómo sacar partido a git worktree, pero todo llegará.
Git es de esas herramientas maravillosas por lo simple y por lo útil.
#3 Se supone que git worktree es para trabajar simultáneamente en varias cosas en el mismo proyecto sin tener que cambiar de rama para cada una de ellas. Sería como tener varias ramas del mismo proyecto desplegadas en diferentes directorios (en el ejemplo lo explica bastante bien: estás trabajando en algo, llega otra cosa más urgente y, en lugar de guardarlo —commit o stash— y ponerte con lo nuevo, lo dejas ahí, haces un worktree en otro directorio y trabajas en él).
Respecto a que es una herramienta simple… pues yo creo que no. Git es complejo y complicado. Pero toda la potencia que da suple con creces toda su complejidad. Y útil, vaya si es útil. Git es increíble.
#16 #10 #4 Git es muy simple. Y se explica con una sola imagen: https://schacon.github.io/gitbook/assets/images/figure/objects-example.png
Un átomo también es simple, pero puede crear cosas muy complejas. Pero el átomo en si es simple.
#25 Quizás la dificultad venga por culpa de quienes venimos de Subversion y de CVS y haya que cambiar conceptos . Pero sí, acepto tu respuesta 😊.
#3 Útil sí. Simple no. Ofuscado más bien.
#10 ¿Tu no conociste CSV ni intentaste hacer un brach & merge con él o con Subversion, verdad?
#20 Ejem, creo que te refieres a CVS
#44 Por supuesto... ¡Así de olvidado lo tengo!
#20 Sí. Con CVS fácil pero muy lento, y con Subversion, fácil y rápido
#48 ¿Rápido Subversion para hacer un branch? Si se hace una copia del repositorio entero...
Quizá si está trabajando con un repo de 10 ficheros vaya bien, pero prueba de hacer lo mismo con un proyecto grande, que con subversion implica unos cuantos minutos y mucho runrún de disco, mientras que en git es instantáneo.
#88 triturador, te equivocas. La copia entera se realiza en el cvs, no en el subversion. Mira el bloque cheap copies en:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html
No digo que sea el sistema más rápido. Posiblemente lo sea más el git o, al menos, tenga facilidades para trabajar con distintas ramas que no tiene el subversion. Digo que por muy grande que sea el directorio a copiar, el tiempo de crear la rama con Subversion es constante y muy bajo.
saludos
#3 totalmente de acuerdo con #10 #16 y #51 git para nada es simple. Trabajar en un proyecto con 3 versiones diferentes que comparten la mayoria del codigo no es para nada simple.
#54 Pues yo uno de los métodos que tengo para diferenciar a los desarrolladores juniors de los seniors, es preguntarles si git les parece complejo.
#61 Ya se sabe, que git va cambiando su complejidad en función de los años que lo lleves usando.
Supongo que también les podrías preguntar por cómo tienen el ojete de dado de sí, es un criterio equivalente.
Git, desde el punto de vista del usuario es una reputa mierda pinchada en un palo. Otra cosa es que eso a los frikis sin vida les encante para presumir de son capaces de traspasar capas de ofuscación y comandos crípticos, muy típico precisamente de los que empiezan y todavía no se cansaron de perder el tiempo aprendiendo a pasar por el aro.
#63 el ojete ya todos lo tienen dado de si al máximo desde becarios...
#63 Teniendo en cuenta que git trae una GUI de serie, que te enseña todo con dibujitos, y que la CLI está perfectamente ordenada y documentada... voy a querer pensar que ni te has molestado en mirarlo.
#66 Claro, claro, no es que tengas un problema psicológico de inseguridad con las herramientas que usas y que no admiten crítica ni mácula ninguna (que ya manda huevos), es que no me he molestado en mirar una herramienta con la que trabajo a diario. Uso git gui a diario y de vez en cuando con CLI, no vas a ahora a enseñarme a mí lo malo y bueno que tiene git.
Háztelo mirar.
#71 Ves... quería pensar que simplemente desconocías git, pero visto lo fácil que saltas con los insultos voy a tener que pensar otra cosa. Pos bueno, pos vale.
#3 bueno bueno, lo de simple no eh! Para nada es simple, es muy facil meter la pata, y tiene, precisamente, infinidad de maneras de hacer la misma operación.
Eso hace que la gente se lie que da gusto. Por ahi lo tildan como un "framework para diseñar flujos de trabajo" jaja
#16 Tan simple como papel y lápiz. Mira si no ha habido gente que la ha liado gorda con solo papel y lápiz.
#3 por lo útil sí. Por lo simple no.
Subversión es muchísimo más simple que git... Y git es más "poderoso".
Muy útil el tema del worktree, es muy tipico el caso de uso de estar trabajando en una feature nueva y que te venga un bug urgente y tienes que andar haciendo stash o algún commit guarrero para cambiar el directorio de trabajo a una nueva rama y hacer un hotfix. De esta forma puedes mantener dos directorios separados en el mismo repo apuntando a cada rama y simplifica los cambios de contexto (que antes también lo podías hacer, pero clonando en varios dir el repositorio que es más coñazo).
Ya puestos podían añadir facilidades para otros flujos de trabajo, como el típico git-flow.
#41 Para git-flow existen extensiones desde hace tiempo que facilitan su uso: https://github.com/petervanderdoes/gitflow Si usas Linux es muy probable que tengas paquetes en la propia distribución, las más conocidas los tienen.
#77 Si a modo de extensiones, incluso en herramientas como SourceTree tienes soporte integrado también. Simplemente decía que se podían integrar como parte del core de git para simplificar y extender aún más su uso.
Típica noticia de MNM para informáticos en portada. Pos vale.
#17 Ya que llegamos vírgenes a los treinta déjanos esto, hombre.
#18 ostras que bien, entonces el año que viene ya me toca!
#22 No te emociones aún. Sólo es una cota inferior.
#78 #75 jugáis con mis sentimientos
#22 Llegar a los 30 no implica que a los 31 vaya a cambiar tu estado, así que relájate.
#17 pues en realidad yo como no informático hace poco he aprendido* a usarlo en proyectos que no son de informática y estoy encantado.
* cuatro comandos, para aprenderlo de verdad supongo que tengo que sacrificar dos cuervos y una oveja, y apuntarme a un retiro espiritual.
#24 Tampoco tanto, llega con la oveja.
#28 #21 #17 etc: a portada llega lo que la gente vota. No todo va a ser noticias sobre corrupción del PP y sobre el león Cecil, que cansinos sois, por favor.
#49 Y al gobierno también llega lo que la gente vota . En mi opinión es algo muy específico y carece de interés general. Pero vamos Rajoy también carece de interés general y ahí está, eso sí, seguiré quejándome así que si te cansa ajoyagua.
#50 Bueno, y si yo me quejo de que tú te quejes, aplícate el mismo ungüento.
#55 pareces del PPSOE diciendo que hago cosas que tú haces. Dónde digo que eres un cansino? Ajoyagua no es quejarse, es decir, te jodes
#17 No todo van a ser noticias para borregos.
#17 En MNM se tratan todos los temas, no solo política
#81 En dónde hablo de política ?
#23 #31 No me malinterpretéis, no tengo nada en contra de que noticias sobre informática lleguen a portada, pero si las características de la nueva versión de Git son relevantes, también lo pueden ser las de la nueva versión de Photoshop, Lightroom, Notepad++, AutoCAD, Google Chrome y así un largo etc...
#34 Eso es discutible. GIT está encabezando una revolución en el desarrollo, hasta el punto de que Github le está quitando protagonismo a Sourceforge, por ejemplo. Cada vez más desarrolladores se están animando a usarlo y a compartir su código con licencia GPL u OpenSource.
En cambio, el software cerrado seguirá siéndolo y cada vez más restrictivo.
No soy desarrollador, pero le veo muchas ventajas a GIT frente a los anteriores controles de versiones como CVS o SVN. Ójala supiese manejarlo mejor.
#35 Cambia las aplicaciones que he escrito ahí por otras con licencia GPL u OpenSource
#38 Pues a mí me parecería bien sin son relevantes (el problema es ese, qué es relevante). De hecho, la categoría “tecnología” está para esto.
#42 Si, si, si he visto que está en la categoría correcta, solo pretendía resaltar mi sorpresa, nada más. Respeto que esté en portada.
#35 ¿le está quitando protagonismo a Sourceforge? Sourceforge esta moribundo hace años.
#34 Todo el que trabaja con datos, trabaja con versiones de documentos; no todo el que trabaja con datos, trabaja con Photoshop (o cualquier otro programa en concreto).
Si te fijas bien, cuando salen funcionalidades nuevas de Chrome, Firefox, o parecidos, también llegan las noticias a portada, por aquello de que también hay mucha gente que los usa.
#34 Yo tampoco entiendo muy bien el criterio la verdad. Hace poco mandé una noticia comentando que WINE va a soportar DX11 y cayó en saco roto. Los caminos de MNM son inescrutables.
Tengo la teoría de que el 95% de los usuarios de Git lo utilizan sin saber muy bien lo que están haciendo.
Sí, Git es muy potente, y muy útil, y todo lo que queráis; pero le falta una capa de abstracción para poder utilizarlo sin tener que conocer sus tripas.
Referencia: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
[...] you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it. [...] It’s understandable that an advanced user might need to know a little about how features are implemented, to grasp subtleties about various commands. But even beginners are quickly confronted with hideous internal details.
#52 Ciertamente git puede resultar un poco arido, y si no tienes muy claro lo que haces cagarla es realmente fácil. En este sentido y sobre todo para gente que empieza un UI tipo SourceTree ayuda bastante a visualizar conceptos y actúa un poco a modo de esa capa de abstracción.
De todos modos el problema principal cuando se usa un CVS no es tanto el no conocer la herramienta como el no tener una politica adecuada de gestion de versiones, por ejemplo tener claro si haces feature-branching con un branch de desarrollo y otro de producción en el mismo repo (modelo git-flow), si haces un desarrollo con un repo central y otro por desarrollador y luego envías cambios con pull request (modelo más tipico en el open-source), si eres un hombre y haces main-line development y no usas ramas en general. Lo importante es entender que politica usas en tu proyecto y porque para luego mapear esa politica con los comandos y conceptos concretos de la herramienta que uses (git, mercurial, svn...), en mi experiencia lo que he visto mucho es que se usan los sitemas de control de versiones sin tener un politica definida y sin entender muy bien que están haciendo, entonces es cuando vienen los problemas.
#52 Comparte ese problema con Subversion.
Desde el eclipse, SVN es excelente, pero por línea de comandos, te querés matar.
Yo lo usé así durante muchos años, pero cualquier cosa difícil se complica bastante, por ejemplo un merge.
Con Git me costó mucho más la primera vez que hice push, pero es mucho más coherente como herramienta, tiene un modelo más fácil de entender. Te podés defender con pocos comandos, y luego ir aprendiendo cada detalle.
Por el lado de la abstracción, puede ser un arma de doble filo. Git te permite hacer cosas bastante sofisticadas, trabajando con árboles. No hay abstracciones fáciles para este, que es un problema difícil. Se puede abstraer algún proceso en particular, tipo git flow, o github flow, pero no parece buena idea para toda la herramienta.
#59 , he trabajado con ambos (Subversion y Git), y la curva de aprendizaje no tiene nada que ver; además, la terminología es muy confusa y muy poco coherente en Git.
Quiero decir, técnicamente puede ser muy bueno, pero cuesta mucho entender cómo funciona; y te apuesto a que mucha gente lo usa sin tener muy claro lo que está haciendo.
#52 Más bien que mucha gente usa Git exactamente igual que como usaba subversion: git commit para cambios, git push para enviarlo "para arriba", y git pull para bajar la última versión. Para eso, podrían quedarse en subversion.
Ahora bien, llegará el día en que querrán/necesitarán hacer algo complicado, y al estar en Git lo podrán hacer. Y entonces lo cogerán el gustillo, y poco a poco irán viendo todo lo que puede hacer Git por ellos más allá del subconjunto de "funcionalidades subversion".
Si a mi me parece difícil y conozco github... Supongo que será cuestión de hacerlo en la práctica.
¿Quieren que usemos directorios de trabajo en lugar de ramas?
git rebase master
https://github.com/git/git/blob/v2.5.0/Documentation/RelNotes/2.5.0.txt
#1 Por lo que se es una "feature" que se viene pidiendo desde hace tiempo. Tener un git dentro de un git.
Eso permite tener subproyectos dentro de proyectos y cosas asi.
#12 Eso sonó muy...
(Sin intentar desmerecer la característica, es lo que me inspiró lo de "subproyectos dentro de proyectos y cosas así")
GIT "es muy sencillo". Mis cojones.
#30 si alguno no lo conocia y lo conoce grcias a esto tal vez aprendan como la mayoria de profesionales consiguen no suicidarse a la hora de hacer control de versiones en sus proyectos por ejemplo. Es didactico y casi para toda la familia
pd: yo lo uso, pero a nivel wannabe, push, commits, merges, clone y poco mas con mi cara de: q clase de magia negra es esta
¿Pero lo de los workdir no estaba ya? Había un comando en la documentación que te permitía hacerlo. Había que copiarlo y ponerle el bit de ejecutable...
#70 Claro, es entrar y es todo noticias sobre IDEs, compiladores y svcs. Porque L'Oreal.
¿Alguien puede explicar para tontos qué hace exactamente Git? (No las novedades, el programa)
#5 Control de versiones, osea, guarda los cambios a todos tus ficheros cuando tu creas conveniente.
En cualquier momento puedes recuperar una versión anterior de un determinado fichero o de todos, por si la has cagao.
#6 Yo uso rsync para eso. ¿tiene algo que ver?
#6 #5 Y no sólo eso, también guarda un historial del desarrollo de software para saber quién ha hecho qué y cuándo (que se suele usar para echar las culpas . De hecho hay un comando, git blame, que se usa para eso; no para echar las cumplas, pero sí para ver quién ha hecho qué).
#30 Yo soy informático, y sinceramente no me parece que esto tenga relevancia para el común de los mortales. Especialmente porque a la mayoría de gente les hablas de cualquier cosa más complicada que un chupete y se les queda cara de poker.
#65 Vamos, que el 99% de Menéame no tiene relevancia para el "común de los mortales".
#30 #65 Creo que os falla un poco la lógica.
Si esto ha llegado a portada, es que a la gente le interesa lo suficiente como para menearlo. Y si a suficiente gente le interesa como para llevarlo a portada, sospecho que los que lo ven irrelevante son bastante menos del 99%.
#90 Amigo, esto va en relación al karma. Unos pocos con mucho karma son mas relevantes que unos muchos con poco.
Buah git ...donde este Mercurial o Bazar
Soy tonto
Mercurial
Por cierto, todos los que piensan que git es "irrelevante" para la mayoria de los usuarios, deverian de saber que gallir usa git para administrar el codigo de meneame
#73 Sigue siendo irrelevante para la mayoría de usuarios de menéame, de la misma forma que muchas casas tienen ventanas de aluminio de rotura de puente térmico y no salen noticias al respecto o no te enteras de las novedades en la maquinaria de producción de motores de coches.
No lleva grafeno?
¿en serio esto está en portada?
#21 Computer science, bitch!
#21 mejor que leer referente a los 4 gallifantes robando o como mueren o roban a la peña ... prefiero esto, si
Me parece de coña que esto llegue a portada.
#28 ¿? es una de las herramientas mas importantes de todo desarrollador a nivel mundial. No solo lo usan los picados.
#29 Supongo que si hay un lobbie muy grande en MNM de informáticos, cualquier noticia especializada en el sector llegará a portada, aunque el 99% de los meneantes no tengan ni idea, ni les importe.