#13:
#10 10 Git anos: una entrevista con la Guardia Civil
#11:
#0 Bien puesta la etiqueta Git, no vaya a ser que alguien quiera buscar esta entrevista al creador de Git, después de 10 años de Git y no encuentre la entrevista al creador de Git, después de 10 de años de Git.
#20:
39 años de GTI: una entrevista con el creador de GTI: VW
#10:
Vosotros os reís de Git, pero sin ello muchos programas casi no existirían hoy en día o sería muy difícil la colaboración en un equipo.
#21:
#18 Hombre, tienes razón, pero al final tus puntos 1 y 2 son los que distinguen a un programador bueno de uno mediocre. Sí, por supuesto pueden haber interfaces gráficas para hacerte las tareas más fáciles, que no se trata de sufrir por sufrir. Pero, generalizando (y las generalizaciones son odiosas y blah blah blah) dudo que un programador que no se sienta cómodo con la línea de comandos pueda ser un buen programador, en general.
Respecto a 3, si es lo que pienso que es y hablamos de github, no creo que sea exclusivo de Windows. A mi me ha pasado lo mismo en Linux y OS X) y lo he solucionado cambiando el remoto para usar SSH (que usa las claves añadidas en https://github.com/settings/ssh ) en lugar de HTTPS (que usa, erm, HTTPS y por tanto usuario y contraseña). https://help.github.com/articles/which-remote-url-should-i-use/
Subversion no lo toco ni con un palo.
#22:
#18 Se que hablas de forma genérica, así que lo siguiente no te lo tomes de forma personal:
Respecto a los puntos que indicas:
1 .- Para ser un buen programador hay que aceptar que vas a estar aprendiendo el resto de tu carrera profesional. Los estudios no van a finalizar al acabar la carrera, el master, doctorado, etc. Si vienes de Subversion será algo complicado adaptarte al nuevo paradigma que expone Git, pero es cuestión de ponerse y practicar un poco. Si no tienes experiencia te costará un poco más, pero para eso está internet, para informarse de las cosas que se desconocen. Git tiene una documentación muy buena: http://git-scm.com/doc
2.- En la web de git hay una sección dedicada exclusivamente a las interfaz gráficas para Git: http://git-scm.com/downloads/guis . Yo suelo usar SmartGit, muy fácil de usar y con versiones para diferentes Sistemas Operativos.
Tanto con Git o Subversion puedes hacer cosas chulas, ya que estas dos aplicaciones solo guardan los cambios de los proyectos que creas. La diferencia principal entre Git y Subversion esta en que Git es distribuido y Subversion no. Me explico:
En Subversion tienes una copia de trabajo, que estará en tu pc, donde realizarás los cambios al código. Una vez finalizados esos cambios los subirás al repositorio, que lo normal es que esté en un servidor. Si el repositorio por cualquier razón se corrompe, tendrás que crear un nuevo repositorio, perdiendo así todo el historial de cambios de tu proyecto, ya que en tu copia de trabajo solo tienes la última versión de proyecto (HEAD) en el que trabajabas, con lo que no podrás recuperarlo.
En Git, la copia de trabajo se convierte en una copia del repositorio, o mejor dicho: una copia del historial de cambios. Esto permite que si el repositorio central se corrompe, no se pierda todo el historial.
#17:
Desde luego, tal y como empieza a hablar ya sabes que es Linus Torvalds
Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM's with a passion.
#18:
Git está bien, pero le veo algunos problemas:
1. Hay que aprender a usarlo y no es para nada intuitivo (git pull, push, state, checkout, ....). Lo sé, pero "aprender" es una cosa a la que mucha gente le tiene fobia. Si tienes un equipo de trabajo y les dicen que tienen que aprender algo nuevo, posiblemente encuentres muchas caras largas. Los españoles no somos de estudiar.
2. Hoy por hoy no creo que exista una interfaz gráfica que reemplace la línea de comandos. Y te encontrarás con la reticencia de muchos desarrolladores (sobre todo si vienen de Güindous, acostumbrados desde siempre a ventanitas). No obligues a un usuario de Güindous a usar la línea de comandos. Es una pérdida de tiempo.
3. Git funciona mejor en Linux. En Windows he encontrado algunos problemas. Por ejemplo, no consigo que recuerde el usuario y la contraseña. Tienes que introducirla una y otra vez si quieres actualizar el repositorio remoto. Y no creo que lo vayan a solucionar, porque Windows es una mierda. No merece la pena.
En fin. Si quieres hacer cosas chulas, usa Git. Si lo que quieres es un repositorio central y no complicarte la vida, usa mejor Subversion.
#0 Bien puesta la etiqueta Git, no vaya a ser que alguien quiera buscar esta entrevista al creador de Git, después de 10 años de Git y no encuentre la entrevista al creador de Git, después de 10 de años de Git.
Desde luego, tal y como empieza a hablar ya sabes que es Linus Torvalds
Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM's with a passion.
1. Hay que aprender a usarlo y no es para nada intuitivo (git pull, push, state, checkout, ....). Lo sé, pero "aprender" es una cosa a la que mucha gente le tiene fobia. Si tienes un equipo de trabajo y les dicen que tienen que aprender algo nuevo, posiblemente encuentres muchas caras largas. Los españoles no somos de estudiar.
2. Hoy por hoy no creo que exista una interfaz gráfica que reemplace la línea de comandos. Y te encontrarás con la reticencia de muchos desarrolladores (sobre todo si vienen de Güindous, acostumbrados desde siempre a ventanitas). No obligues a un usuario de Güindous a usar la línea de comandos. Es una pérdida de tiempo.
3. Git funciona mejor en Linux. En Windows he encontrado algunos problemas. Por ejemplo, no consigo que recuerde el usuario y la contraseña. Tienes que introducirla una y otra vez si quieres actualizar el repositorio remoto. Y no creo que lo vayan a solucionar, porque Windows es una mierda. No merece la pena.
En fin. Si quieres hacer cosas chulas, usa Git. Si lo que quieres es un repositorio central y no complicarte la vida, usa mejor Subversion.
#18 Hombre, tienes razón, pero al final tus puntos 1 y 2 son los que distinguen a un programador bueno de uno mediocre. Sí, por supuesto pueden haber interfaces gráficas para hacerte las tareas más fáciles, que no se trata de sufrir por sufrir. Pero, generalizando (y las generalizaciones son odiosas y blah blah blah) dudo que un programador que no se sienta cómodo con la línea de comandos pueda ser un buen programador, en general.
Respecto a 3, si es lo que pienso que es y hablamos de github, no creo que sea exclusivo de Windows. A mi me ha pasado lo mismo en Linux y OS X) y lo he solucionado cambiando el remoto para usar SSH (que usa las claves añadidas en https://github.com/settings/ssh ) en lugar de HTTPS (que usa, erm, HTTPS y por tanto usuario y contraseña). https://help.github.com/articles/which-remote-url-should-i-use/
#18 Se que hablas de forma genérica, así que lo siguiente no te lo tomes de forma personal:
Respecto a los puntos que indicas:
1 .- Para ser un buen programador hay que aceptar que vas a estar aprendiendo el resto de tu carrera profesional. Los estudios no van a finalizar al acabar la carrera, el master, doctorado, etc. Si vienes de Subversion será algo complicado adaptarte al nuevo paradigma que expone Git, pero es cuestión de ponerse y practicar un poco. Si no tienes experiencia te costará un poco más, pero para eso está internet, para informarse de las cosas que se desconocen. Git tiene una documentación muy buena: http://git-scm.com/doc
2.- En la web de git hay una sección dedicada exclusivamente a las interfaz gráficas para Git: http://git-scm.com/downloads/guis . Yo suelo usar SmartGit, muy fácil de usar y con versiones para diferentes Sistemas Operativos.
Tanto con Git o Subversion puedes hacer cosas chulas, ya que estas dos aplicaciones solo guardan los cambios de los proyectos que creas. La diferencia principal entre Git y Subversion esta en que Git es distribuido y Subversion no. Me explico:
En Subversion tienes una copia de trabajo, que estará en tu pc, donde realizarás los cambios al código. Una vez finalizados esos cambios los subirás al repositorio, que lo normal es que esté en un servidor. Si el repositorio por cualquier razón se corrompe, tendrás que crear un nuevo repositorio, perdiendo así todo el historial de cambios de tu proyecto, ya que en tu copia de trabajo solo tienes la última versión de proyecto (HEAD) en el que trabajabas, con lo que no podrás recuperarlo.
En Git, la copia de trabajo se convierte en una copia del repositorio, o mejor dicho: una copia del historial de cambios. Esto permite que si el repositorio central se corrompe, no se pierda todo el historial.
#33 ¿Has tenido que pegarte para montar un CVS antiguo? ¿Incluso un Subversion? Porque en comparación... recuerdo pocas torturas como tener que montar alguno de esos dos desde cero.
Y con Git una vez tienes un poco en la cabeza el mecanismo del GitFlow, lo de las branches y demás es de coña, aunque asuste un poco al principio -pero una vez lo ves como features, hotfixes y demás, todo cobra sentido-. Como dice #31 con SourceTree (o como #22, yo uso SmartGit para Linux en el trabajo) es facilísimo. Y con un Redmine para gestionarlo todo ya es la ostia.
#18 Ya te han rebatido todos los puntos. Bajo mi punto de vista Git nos ha liberado del "repositorio central" y nos ha permitido tener cosas como etckeeper, o simplemente usar git en un directorio donde tienes guardados ficheros de texto, ... La maravilla que es hacer un git init en cualquier directorio y empezar a hacer commits es impagable.
#18 Aporto mi granito de arena respecto a los otros comentarios:
1 Si tienes un equipo de trabajo que no quiere usar las mejores herramientas y no esta dispuesto a aprender y adaptarse... mejor cambia de equipo de trabajo. Git es complejo, si, pero como lo es un formula 1, para proyectos sencillos no vale, pero a poco complejo que sea el proyecto merece la pena y es imprescindible en cuanto quieres tener control de verdad sobre las versiones.
2 (y casi 3) Si la hay, se llama Git Extensions, y es la única con la que he podido hacer todo, al resto le han faltado cosas como una buena importación de un repositorio externo svn, o no tenían para pasar trozos de ficheros (no el fichero entero) etc... y si por si fuera poco, una opción de menú en herramientas llamada GIt Bash que te abre una linea de comandos unix , es GPL, y consume la mitad de memoria que las otras que te han comentado. Lo malo, que esta hecha en .NET y es muy complicado portarla a linux/mono.
3 A ese problema me he enfrentado hace poco, si te instalas el git extensions ya te viene, pero sino hay un programa llamado git-credential-winstore que te guarda las contraseñas, se configura solo, pero si sale mal solo tienes que poner en el .gitconfig de tu usuario esto (sin las primeras comillas) "[credential]
helper = !"C:/Program Files (x86)/GitExtensions//GitCredentialWinStore/git-credential-winstore.exe""
#18 A mi usar linea de comandos me parece realmente util cuando tienes que hacer cosas de scripting, pero claro, para recien llegados supongo que es mas duro.
Yo en vez de herramienta grafica uso este alias cuando quiero hacerme una idea general del repo, por si a alguien le resulta util:
#18 Está claro que no es facil, pero ¿qué tipo de software para desempeñar una tarea compleja es facil hoy en día? Autocad, mathlab, photoshop...
El concepto de un sistema de control de versiones no está al alcance de culaquiera, pero no por una cuestión de como esté diseñado el cliente, sino por una cuestión conceptual. Mucha gente, incluso programadores, no entienden la diferencia de concepto entre una simple copia de seguridad y un versionado de un SVN o GIT. He escuchado en multiples ocasiones "¿Backup para qué? Si ya tenemos el svn!"
Por ahora, salvo sistemas de versionado que vienen integrados en softwares de trabajo, lo veo una herramienta para usuarios inquietos o avanzados.
Git sería un programa cojonudo si tuviese una documentación decente y una interfaz (ya no digo gráfica, pero sí de CLI) que no fuese un amasijo de terminología críptica y comandos que no tienen nada que ver con lo que parece que hacen.
Git simplemente se queda en un programa muy eficaz pero extremadamente críptico que puede putearte debido a ello.
Personalmente no me parece muy positivo que haya que andar consultando por ahí que es lo que hacen comandos básicos o al revés, cómo narices se hacen cosas básicas porque no hay comandos sencillos para hacerlas.
Resumiendo: git podría ser mucho mejor de lo que es si se pusiese algún esfuerzo en hacerlo medianamente usable. Pero muy en la línea del FOSS, se prefiere lo arcano para satisfacer egos. Muy útil, pero muchas veces una molestia que hace perder tiempo de forma absurda.
#23 Si te quedas en lo que hacen SVN y demás, Git es igual o más sencillo de usar (en lo que a comandos se refiere). Es la potente simplicidad de Git, y la cantidad de cosas que permite hacer que son imposibles en el resto de VCS, lo que le puede hacer parecer difícil de usar.
De todas formas, una vez pasado el periodo inicial, me parece bastante sencillo de usar, y que ofrece información bastante útil. ¿Qué es lo que te parece complicado de usar?
Una de las cosas que más me gusta de git es que puedes crearte tus propios comandos poniendo en el path ejecutables con el nombre git-mycommand Yo tengo un par que me parecen muy útiles.
#23 Bueno, tampoco es para tanto... con Eclipse no es nada complicado hacer un puñetero commit o un checkout en un remoto. Si se entiende un poco de snapshots no la cagas con el tema de ramas y tal. Recomiendo echar un ojo al libro Pro Git. Es gratis (En la misma web de Git está), y se lee rápido, deja conceptos claros.
Estos comentarios forococheros sobran totalmente. Espero que la gente se anime a votarlos negativo. El primero de todos supongo que está hecho para remarcar que hay "dos puntos" dos veces seguidas, pero luego el meme ridículo desvirtúa esta web. Por desgracia cada día hay más
Me sorprende que muchos comentarios hablan de lo complicado que son los comandos de git... Personalmente venía de muchos años trabajando con svn y pasarme a git fue cuestión de días. Básicamente se puede hacer el mismo trabajo que con svn haciendo la siguiente equivalencia
Obviamente trabajar así no es trabajar con el flujo de trabajo de git habitual (lo que se llama GitFlow), pero para pasarse desde svn creo que es más que suficiente.
A mi ahora me toca trabajar otra vez con svn y echo tanto de menos el poder hacer commits y ramas en local (genial para esos momentos en que se va internet en la oficina), ver historial de cambios de manera rápida, jugar con los tags...
Este tío no sólo creó un sistema operativo usado por millones de personas cada día sino que además creo Git que ha hecho que se desarrollasen fácilmente muchas aplicaciones que conocemos ahora. Un grande.
bueno yo siempre usé SVN, luego me toco cambiar a Rational Team Concept de IBM, su control del código es muy parecido a git, creandote repositorios locales, y ahora estoy con git y me fue sencillo. De todos modos git digamos te obliga a trabajar de esta manera, pero eso no quiere decir que en SVN no pudieras simularlo creando tu rama propia y haciendo un merge...
#76 exacto, me refería que tampoco es que sea una idea superevolucionaria pero git te da más comodidad, para mi es como SVN 2.0 por decirlo de alguna manera.
Comentarios
#0 Bien puesta la etiqueta Git, no vaya a ser que alguien quiera buscar esta entrevista al creador de Git, después de 10 años de Git y no encuentre la entrevista al creador de Git, después de 10 de años de Git.
#11 gracias, llevo toda la tarde pensando en qué etiquetas iba a poner
39 años de GTI: una entrevista con el creador de GTI: VW
Vosotros os reís de Git, pero sin ello muchos programas casi no existirían hoy en día o sería muy difícil la colaboración en un equipo.
#10 10 Git anos: una entrevista con la Guardia Civil
#13
#13 Tu ganas.
#10 Bueno, ya había sistemas de control de versiones previos a Git.
#19 Y que eran un horror.
#30 :facepalm: :pena: :tristeza:
#10 antes de Git hoy había otros sistemas de control de versiones, como CVS o Subversion.
10 años de creador: un GIT con el Linus Torvalds: el entrevistador
Desde luego, tal y como empieza a hablar ya sabes que es Linus Torvalds
Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM's with a passion.
#17 LOL LOL LOL
Ahora en serio, la entrevista está muy bien. Denme karma
10 años de GIT: una entrevista con el creador de Git: Linus Torvalds
#1 10 años de Torvalds: un creador de la entrevista de GIT: GIT.
13 años de GIT: una entrevista con el creador de Git: Linus Torvalds
Git está bien, pero le veo algunos problemas:
1. Hay que aprender a usarlo y no es para nada intuitivo (git pull, push, state, checkout, ....). Lo sé, pero "aprender" es una cosa a la que mucha gente le tiene fobia. Si tienes un equipo de trabajo y les dicen que tienen que aprender algo nuevo, posiblemente encuentres muchas caras largas. Los españoles no somos de estudiar.
2. Hoy por hoy no creo que exista una interfaz gráfica que reemplace la línea de comandos. Y te encontrarás con la reticencia de muchos desarrolladores (sobre todo si vienen de Güindous, acostumbrados desde siempre a ventanitas). No obligues a un usuario de Güindous a usar la línea de comandos. Es una pérdida de tiempo.
3. Git funciona mejor en Linux. En Windows he encontrado algunos problemas. Por ejemplo, no consigo que recuerde el usuario y la contraseña. Tienes que introducirla una y otra vez si quieres actualizar el repositorio remoto. Y no creo que lo vayan a solucionar, porque Windows es una mierda. No merece la pena.
En fin. Si quieres hacer cosas chulas, usa Git. Si lo que quieres es un repositorio central y no complicarte la vida, usa mejor Subversion.
#18 Hombre, tienes razón, pero al final tus puntos 1 y 2 son los que distinguen a un programador bueno de uno mediocre. Sí, por supuesto pueden haber interfaces gráficas para hacerte las tareas más fáciles, que no se trata de sufrir por sufrir. Pero, generalizando (y las generalizaciones son odiosas y blah blah blah) dudo que un programador que no se sienta cómodo con la línea de comandos pueda ser un buen programador, en general.
Respecto a 3, si es lo que pienso que es y hablamos de github, no creo que sea exclusivo de Windows. A mi me ha pasado lo mismo en Linux y OS X) y lo he solucionado cambiando el remoto para usar SSH (que usa las claves añadidas en https://github.com/settings/ssh ) en lugar de HTTPS (que usa, erm, HTTPS y por tanto usuario y contraseña).
https://help.github.com/articles/which-remote-url-should-i-use/
Subversion no lo toco ni con un palo.
#18 Se que hablas de forma genérica, así que lo siguiente no te lo tomes de forma personal:
Respecto a los puntos que indicas:
1 .- Para ser un buen programador hay que aceptar que vas a estar aprendiendo el resto de tu carrera profesional. Los estudios no van a finalizar al acabar la carrera, el master, doctorado, etc. Si vienes de Subversion será algo complicado adaptarte al nuevo paradigma que expone Git, pero es cuestión de ponerse y practicar un poco. Si no tienes experiencia te costará un poco más, pero para eso está internet, para informarse de las cosas que se desconocen. Git tiene una documentación muy buena: http://git-scm.com/doc
2.- En la web de git hay una sección dedicada exclusivamente a las interfaz gráficas para Git: http://git-scm.com/downloads/guis . Yo suelo usar SmartGit, muy fácil de usar y con versiones para diferentes Sistemas Operativos.
3.- No recuerdo como hacía los push en Windows, hace ya unos cuantos años que no uso Windows, pero espero que esta solución te pueda servir: http://stackoverflow.com/questions/5343068/is-there-a-way-to-skip-password-typing-when-using-https-github . Otro, de la documentaciónd e Git: http://git-scm.com/book/es/v2/Git-Tools-Credential-Storage
Tanto con Git o Subversion puedes hacer cosas chulas, ya que estas dos aplicaciones solo guardan los cambios de los proyectos que creas. La diferencia principal entre Git y Subversion esta en que Git es distribuido y Subversion no. Me explico:
En Subversion tienes una copia de trabajo, que estará en tu pc, donde realizarás los cambios al código. Una vez finalizados esos cambios los subirás al repositorio, que lo normal es que esté en un servidor. Si el repositorio por cualquier razón se corrompe, tendrás que crear un nuevo repositorio, perdiendo así todo el historial de cambios de tu proyecto, ya que en tu copia de trabajo solo tienes la última versión de proyecto (HEAD) en el que trabajabas, con lo que no podrás recuperarlo.
En Git, la copia de trabajo se convierte en una copia del repositorio, o mejor dicho: una copia del historial de cambios. Esto permite que si el repositorio central se corrompe, no se pierda todo el historial.
Git tiene más mejoras: http://es.wikipedia.org/wiki/Git
#22 Gracias por sugerir SmartGit. Lo probaré a ver qué tal.
#25 Yo uso SourceTree, de la gente que hace JIRA y me parece una herramienta muy buena
#33 ¿Has tenido que pegarte para montar un CVS antiguo? ¿Incluso un Subversion? Porque en comparación... recuerdo pocas torturas como tener que montar alguno de esos dos desde cero.
Y con Git una vez tienes un poco en la cabeza el mecanismo del GitFlow, lo de las branches y demás es de coña, aunque asuste un poco al principio -pero una vez lo ves como features, hotfixes y demás, todo cobra sentido-. Como dice #31 con SourceTree (o como #22, yo uso SmartGit para Linux en el trabajo) es facilísimo. Y con un Redmine para gestionarlo todo ya es la ostia.
#31 Hasta que intentas bajarte la versión de Linux y descubres que los lumbreras lo programaron en .net.
#18 Ya te han rebatido todos los puntos. Bajo mi punto de vista Git nos ha liberado del "repositorio central" y nos ha permitido tener cosas como etckeeper, o simplemente usar git en un directorio donde tienes guardados ficheros de texto, ... La maravilla que es hacer un git init en cualquier directorio y empezar a hacer commits es impagable.
#18 prueba SourceTree. De nada. Para Linux no he conseguido encontrar nada igual de decente, así que toca tirar de comandos.
#18 Yo vengo de muchos años usando perforce, TFS y SVN. De ahí he pasado a git y siempre por línea de comandos.
No vuelvo atrás.
#18 Aporto mi granito de arena respecto a los otros comentarios:
1 Si tienes un equipo de trabajo que no quiere usar las mejores herramientas y no esta dispuesto a aprender y adaptarse... mejor cambia de equipo de trabajo. Git es complejo, si, pero como lo es un formula 1, para proyectos sencillos no vale, pero a poco complejo que sea el proyecto merece la pena y es imprescindible en cuanto quieres tener control de verdad sobre las versiones.
2 (y casi 3) Si la hay, se llama Git Extensions, y es la única con la que he podido hacer todo, al resto le han faltado cosas como una buena importación de un repositorio externo svn, o no tenían para pasar trozos de ficheros (no el fichero entero) etc... y si por si fuera poco, una opción de menú en herramientas llamada GIt Bash que te abre una linea de comandos unix , es GPL, y consume la mitad de memoria que las otras que te han comentado. Lo malo, que esta hecha en .NET y es muy complicado portarla a linux/mono.
3 A ese problema me he enfrentado hace poco, si te instalas el git extensions ya te viene, pero sino hay un programa llamado git-credential-winstore que te guarda las contraseñas, se configura solo, pero si sale mal solo tienes que poner en el .gitconfig de tu usuario esto (sin las primeras comillas) "[credential]
helper = !"C:/Program Files (x86)/GitExtensions//GitCredentialWinStore/git-credential-winstore.exe""
#18 quien tenga fobia a aprender que no se dedique a la informática, lo veo así de simple...
#18 A mi usar linea de comandos me parece realmente util cuando tienes que hacer cosas de scripting, pero claro, para recien llegados supongo que es mas duro.
Yo en vez de herramienta grafica uso este alias cuando quiero hacerme una idea general del repo, por si a alguien le resulta util:
log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white) - %an%C(reset)%C(bold yellow)%d%C(reset)' --all
#18 Está claro que no es facil, pero ¿qué tipo de software para desempeñar una tarea compleja es facil hoy en día? Autocad, mathlab, photoshop...
El concepto de un sistema de control de versiones no está al alcance de culaquiera, pero no por una cuestión de como esté diseñado el cliente, sino por una cuestión conceptual. Mucha gente, incluso programadores, no entienden la diferencia de concepto entre una simple copia de seguridad y un versionado de un SVN o GIT. He escuchado en multiples ocasiones "¿Backup para qué? Si ya tenemos el svn!"
Por ahora, salvo sistemas de versionado que vienen integrados en softwares de trabajo, lo veo una herramienta para usuarios inquietos o avanzados.
12 años de GIT: una entrevista con el creador de Git: Linus Torvalds
11 años de GIT: una entrevista con el creador de Git: Linus Torvalds
10 años de GIT: una entrevista con el creador de Git: Linus Torvalds
14 años de GIT: una entrevista con el creador de Git: Linus Torvalds
por cierto, melafo a la entrevistadora
10 años de GIT: una entrevista con el creador de Git: Linus Torvalds
PD: me gusta más SVN.
#24 Qué dices, Visual SourceSafe, el mejor. Bueno, siempre después de _final, _final_final y _final_final_ok
10 sombras de torvalds con un melafo a la entrevistadora y un GIT de cuero como consolador
Git sería un programa cojonudo si tuviese una documentación decente y una interfaz (ya no digo gráfica, pero sí de CLI) que no fuese un amasijo de terminología críptica y comandos que no tienen nada que ver con lo que parece que hacen.
Git simplemente se queda en un programa muy eficaz pero extremadamente críptico que puede putearte debido a ello.
Personalmente no me parece muy positivo que haya que andar consultando por ahí que es lo que hacen comandos básicos o al revés, cómo narices se hacen cosas básicas porque no hay comandos sencillos para hacerlas.
Resumiendo: git podría ser mucho mejor de lo que es si se pusiese algún esfuerzo en hacerlo medianamente usable. Pero muy en la línea del FOSS, se prefiere lo arcano para satisfacer egos. Muy útil, pero muchas veces una molestia que hace perder tiempo de forma absurda.
#23 Si te quedas en lo que hacen SVN y demás, Git es igual o más sencillo de usar (en lo que a comandos se refiere). Es la potente simplicidad de Git, y la cantidad de cosas que permite hacer que son imposibles en el resto de VCS, lo que le puede hacer parecer difícil de usar.
De todas formas, una vez pasado el periodo inicial, me parece bastante sencillo de usar, y que ofrece información bastante útil. ¿Qué es lo que te parece complicado de usar?
Una de las cosas que más me gusta de git es que puedes crearte tus propios comandos poniendo en el path ejecutables con el nombre git-mycommand Yo tengo un par que me parecen muy útiles.
#28 hombre... git sencillo de usar. A mi me costó un huevo. (no liarla de vez en cuando, quiero decir y tener cierta soltura)
#23 Git simplemente se queda en un programa muy eficaz pero extremadamente críptico que puede putearte debido a ello.
Exactamente igual que el propio Linus Torvalds; no se puede negar que el programa es obra suya
CC: #28 #33
#23 Bueno, tampoco es para tanto... con Eclipse no es nada complicado hacer un puñetero commit o un checkout en un remoto. Si se entiende un poco de snapshots no la cagas con el tema de ramas y tal. Recomiendo echar un ojo al libro Pro Git. Es gratis (En la misma web de Git está), y se lee rápido, deja conceptos claros.
10 años de GIT: una entrevista con el creador de Git: Linus Torvalds
Estos comentarios forococheros sobran totalmente. Espero que la gente se anime a votarlos negativo. El primero de todos supongo que está hecho para remarcar que hay "dos puntos" dos veces seguidas, pero luego el meme ridículo desvirtúa esta web. Por desgracia cada día hay más
Me sorprende que muchos comentarios hablan de lo complicado que son los comandos de git... Personalmente venía de muchos años trabajando con svn y pasarme a git fue cuestión de días. Básicamente se puede hacer el mismo trabajo que con svn haciendo la siguiente equivalencia
- svn update => git pull
- svn commit => git commit && git push
Obviamente trabajar así no es trabajar con el flujo de trabajo de git habitual (lo que se llama GitFlow), pero para pasarse desde svn creo que es más que suficiente.
A mi ahora me toca trabajar otra vez con svn y echo tanto de menos el poder hacer commits y ramas en local (genial para esos momentos en que se va internet en la oficina), ver historial de cambios de manera rápida, jugar con los tags...
Errónea. No es Git, es GNU/Git.
Si alguien tiene tiempo y quiere realmente entender cómo funciona git, lo sencillo que realmente es, y porqué es la maravilla que es, que se lea la "parábola de Git":
http://tom.preston-werner.com/2009/05/19/the-git-parable.html
Git es una estructura de datos bastante simple http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
git rebase --onto master Linus
Este tío no sólo creó un sistema operativo usado por millones de personas cada día sino que además creo Git que ha hecho que se desarrollasen fácilmente muchas aplicaciones que conocemos ahora. Un grande.
#45 Y luego, le da por bucear, y pasa lo que pasa: http://subsurface-divelog.org/
10 años de Torvalds; una entrevista con el creador de Linus: GIT
Mercurial
#56 Menos mal, alguien con cabeza
#63 Lo comentaba para todos aquéllos que dicen que git no les va bien en Windows
#72 Hombre, hace años que es perfectamente estable en Windows. Yo uso tanto Git como Mercurial. Pero prefiero Mercurial.
#74 Sí, yo tenía esa sensación también, pero por lo que he leído en el hilo, algún comentarista dice que no le acaba de ir bien el git en Win
A mi me da lo mismo GIT que SVN (CVS mejor ni lo nombramos). Pero como encuentre al cabrón que creo al chivato de Jenkins ya tiene campo para correr.
Como mola el tío este. Incluso puedo escuchar su voz en la entrevista...
Pregunta, si son 10 años de GIT: ¿Por qué entrevistan al creador de Git: Linus Torvalds?
00110001 00110000 00100000 01100001 11000011 10110001 01101111 01110011 00100000 01100100 01100101 00100000 01000111 01001001 01010100 00111010 00100000 01110101 01101110 01100001 00100000 01100101 01101110 01110100 01110010 01100101 01110110 01101001 01110011 01110100 01100001 00100000 01100011 01101111 01101110 00100000 01100101 01101100 00100000 01100011 01110010 01100101 01100001 01100100 01101111 01110010 00100000 01100100 01100101 00100000 01000111 01101001 01110100 00111010 00100000 01001100 01101001 01101110 01110101 01110011 00100000 01010100 01101111 01110010 01110110 01100001 01101100 01100100 01110011 00101110
bueno, eso
#59 Solo hay 10 tipos de personas. Los que saben binario y los que no
70 años de GIT: una entrevista con el creador de Git: Linus Torvalds.
Sólo puedo darle las gracias, a él y sus colaboradores. Estoy aprendiendo Git y es una maravilla.
10 años de GIT: una entrevista con el creador de Git: Linus Torvalds
Hay cosas mejores que GIT. Las minas antipersona, por ejemplo.
#37 si tuviese karma te votaba positivo. Gracias por hacerme un poco más feliz antes de hacer commit e ir a dormir.
10 años de GIT: una entrevista con el creador de Git: Linus Torvalds
10 años de GIT: una entrevista con el creador de Git: Linux Torvalds 2.0
cuando conseguí dominar svn va y sale el git, ché
bueno yo siempre usé SVN, luego me toco cambiar a Rational Team Concept de IBM, su control del código es muy parecido a git, creandote repositorios locales, y ahora estoy con git y me fue sencillo. De todos modos git digamos te obliga a trabajar de esta manera, pero eso no quiere decir que en SVN no pudieras simularlo creando tu rama propia y haciendo un merge...
#61 Poder se puede, pero buena suerte creando ramas de un repositorio grande con subversion...
#76 exacto, me refería que tampoco es que sea una idea superevolucionaria pero git te da más comodidad, para mi es como SVN 2.0 por decirlo de alguna manera.
HIJOS DE PUTA MARICONES TODOS
#36 Grande!
#36 Eso también te incluye a ti
#36 Mis dies.