881
Diez años de Git: una entrevista con el creador - Linus Torvalds
Esta semana fue de diez años a partir de la fecha en que los desarrolladores del kernel de Linux se encuentran con un obstáculo: que ya no podían utilizar su sistema de control de versiones BitKeeper y ningún otro sistema de control de código fuente no cumplía con sus exigencias en términos de recursos distribuidos. Linus Torvalds, creador de Linux, aceptó el reto y desapareció el fin de semana a aparecer la próxima semana con Git. Hoy, Git se utiliza en miles de proyectos y Git empujado programación en grupos de desarrolladores al nuevo nivel social.
Para conmemorar esta fecha, le pedimos a Linus para compartir la historia oculta de la creación de Git, nos dicen lo que piensa acerca de este proyecto y su impacto en el desarrollo de productos de software. Lo encontrarás en los comentarios a continuación el texto. Para esta entrevista las siguientes semanas, Git, en el que cada día vamos a considerar los proyectos individuales que utilizan el sistema de control de versiones. Esperar historias se desarrollan KVM, Qt, Drupal, Marioneta, vino, y muchos otros.
¿Por qué te prepara Git?
Torvalds: De hecho, yo nunca quise hacer el sistema de control de versiones (LES) y sentí que era justo lo menos interesante en el mundo de la informática (con la posible excepción de las bases de datos; ^) y yo apasionadamente odiado todos estos sistemas. Pero entonces llegó BitKiper (BK) y realmente cambiado la forma en que veía en el control de código fuente. BK hizo muchas cosas bien. Y la capacidad de mantener una copia local del repositorio y el código de combinación distribuida era una buena cosa. Una característica importante del modelo de control de versiones distribuido es que elimina uno de los problemas más graves de SLE - una política de quienes pueden hacer cambios. BK ha demostrado que se puede evitar simplemente distribuyendo todo repositorio. Pero BK tenía sus propios problemas; Varias soluciones técnicas conduce a un problema (cambio de nombre fue dolorosa), pero lo peor fue el hecho de que, dado que BK no se distribuye con el software de código abierto, y fue una gran cantidad de personas que no quieren usarlo. Así que terminamos que había varios desarrolladores importantes utilizando BK, que era libre para su uso en proyectos de código abierto, pero nunca llegó a ser generalmente aceptados. Así que es (VC) ha ayudado en el desarrollo del kernel, pero todavía sigue siendo momentos enfermos.
Se me ocurrió cuando Tridge (Andrew Tridgell) comenzó a la ingeniería inversa de un protocolo simple de BK, que era una violación de las normas de uso de BK. Pasé un par de semanas (meses? Así es como me sentí y) tratando de mediar entre el Tridge y Larry McVoy, pero con el tiempo se hizo evidente que simplemente no funciona. Así que, en algún momento, decidí que ya no puedo seguir utilizando BK, pero yo también no quiero volver a los peores días que eran antes de la BK. Es triste que si bien había otras herramientas para la LES, que hasta cierto punto trataron de utilizar un modelo de desarrollo distribuido, pero ninguno de ellos funcionó bien en el caso de uso a distancia. Yo tenía mis propios requisitos de desempeño, que son aproximadamente incluso no podía estar satisfecho con lo que estaba disponible; y yo también estoy preocupado por la integridad del código y el proceso de diseño, por lo que me decidí a escribir el suyo.
¿Cómo llegaste a esto? Usted escribió todo el fin de semana o simplemente la hora habitual?
Torvalds: Eh. Usted, por cierto, se puede ver cómo todo se tomó la forma de un repositorio Git código fuente, excepto para el primer día o algo así. El día fue dedicado a tratar de convertirse en un Git sí para hospedar para que pueda empezar a usar Git compromete en Git. Por lo tanto, el primer día o algo así, no está presente en la historia, pero todo lo demás - no. El trabajo principal se llevó a cabo principalmente durante el día, pero hay un par de discos y un par de medianoche - después de las dos de la mañana. Lo más interesante es la rapidez con que tomó la forma. La primera se comprometen en el Git árbol - no es un montón de código, pero sí lo básico - lo suficiente para cometer una de sí mismo. El truco no era tanto la codificación como para entender cómo Git tiene que organizar los datos.
Me gustaría hacer hincapié en que a pesar de que se ha recogido durante diez días o algo así (en el que hice mi primer git commit al repositorio del kernel de Linux), no fue de ninguna manera la codificación loco. El volumen de este código temprana es lo suficientemente pequeño, todo dependía de la aplicación correcta de las ideas básicas. Y así pasé algún tiempo "muele" antes del lanzamiento de la totalidad del proyecto. He visto los problemas de los demás. Vi lo que quería evitar.
Tanto si se aumenta (Git) para el nivel de sus expectativas? ¿Qué tan bien (Git) trabaja en sus estimaciones? ¿Hay alguna restricción?
Torvalds: Estoy muy contento con Git. Funciona excepcionalmente bien con el código del núcleo y seguir siendo mis expectativas. Lo que es interesante es el hecho de que haya tomado tanto muchos otros proyectos. Sorprendentemente rápidamente al final. Hay una gran cantidad de inercia en el cambio de uno a otro SLE; Basta con mirar el tiempo que se mantuvo en uso hasta CVS y RCS, pero en algún momento, Git y tomó su caso.
¿Qué piensa usted, ¿por qué es (Git) ha sido tan ampliamente adoptado en uso?
Torvalds: Creo que mucha gente se siente molesto por los mismos problemas que me hicieron odio LES. Y si bien había muchos proyectos en un intento de solucionar uno o dos pequeños problemas que sacar a la gente de sí mismos, de hecho no había nada como Git, que realmente ayudó a no tomar los grandes problemas en la cabeza. Incluso cuando la gente no entiende la importancia de un modelo de desarrollo distribuido (y muchas personas lucharon con esto), entonces tan pronto como se dieron cuenta de que permite realizar copias de seguridad más ligeras y fiables y permite que la gente haga su propio repositorio sin tener que pensar en la política en la resolución de grabación repositorio concreto, nunca miraron hacia atrás.
¿Será Git siempre existe o anticipar una revisión de LES en los próximos diez años? ¿Será usted uno de los que escribió?
Torvalds: No, voy a ser el uno para escribirla. Y tal vez veremos algo nuevo durante diez años, pero te garantizo que va a ser algo muy Git-como. No en el sentido de que en Git bien, pero en el sentido de que Git tiene las características básicas derecho dentro de esa otra LES nunca antes lo había hecho.
Sin falsa modestia;)
¿Por qué Git funciona tan bien en Linux?
Torvalds: Bueno, Git fue creado por nuestro trabajo, ya que es parte de ella. Ya he mencionado un modelo distribuido muchas veces, pero tiene sentido recordar una vez más la misma. Pero Git también se ha establecido para ser muy eficaz para un gran proyecto como Linux, y está escrito que ver lo que la gente considera un desafío antes del advenimiento de Git -. Porque estas son las cosas que hago todos los días
Así por ejemplo: el concepto de la fusión era visto como algo muy doloroso y difícil en muchos LES. Hubieras tenido que planificar su drenaje, porque eran un asunto serio. Esto no me está ustaivaet ya que suelo hacer decenas de fusiones en el día cuando estoy en una ventana de tiempo de la fusión, y aún así, la carga de trabajo no debe estar en la fusión, y el código de la prueba. La fusión en sí toma un par de segundos, es mucho más interesado en escribir para explicar la fusión.
Así, Git fue construido y escrito para mis necesidades. Y así sucede.
La gente decía que Git - sólo para la gente súper inteligentes. Incluso Andrew Morton (Andrew Morton) dijo que Git «Git diseñado para que se sienta aún más estúpido que antes". ¿Cuál sería su respuesta a eso?
Torvalds: Bueno, creo que fue en un primer momento, pero esto ya no es el caso. Hay varias razones por las que la gente se siente así, pero creo que eso es sólo una de las razones para quedarse. El que permanece, es muy simple: "usted puede hacerlo de diferentes maneras»
.
Usted puede hacer muchas cosas usando Git, y muchas de las reglas acerca de lo que debe hacer no proviene de las limitaciones técnicas, sino porque lo que funciona bien cuando tienes que interactuar con otras personas. Git es un potente conjunto de herramientas que pueden sobrecargar el principio, pero también significa que a menudo se pueden hacer las mismas o parecidas cosas de diferentes maneras y que todo funcionaba. En general, la mejor manera de aprender Git, probablemente, es simplemente hacer las cosas simples y ni siquiera mirar a otras cosas, siempre y cuando usted no está seguro con respecto a los conceptos básicos.
Hay varias razones históricas para la percepción de Git como una cosa compleja. Uno de ellos - el hecho de que era muy difícil. Aquellas personas que comenzaron a usar Git antes que nadie a trabajar con el núcleo Linux, realmente tuvieron que aprender a usar un juego bastante complicado de secuencias de comandos para que todo funcione. Todos los esfuerzos se orientaron a conseguir trabajar la tecnología de la base y un poco - de hecho, para hacer más fácil o evidente. Y Git, por supuesto, tenía una reputación que proporciona el conocimiento de lo que estaba haciendo antes. Sin embargo, era cierto en general durante los primeros seis meses o un año.
Otra razón por la que las personas se sentían como Git - una cosa complicada que Git es muy peculiar. Hay personas que disfrutan de las cosas tales como CVS durante una década o dos, y Git - no CVS. Ni siquiera similar. Diferentes conceptos. Equipos difieren. Git nunca trató de parecer como CVS, y viceversa. Y, si se ha utilizado el sistema similar a CVS, por mucho tiempo, da la impresión de complejidad y las diferencias sin causa Git. Las personas fueron rechazados los números de versión del sistema extraño. ¿Por qué el número de versión de Git «1.3.1», pero no tan bien hecho con un número creciente en las versiones de CVS? ¿Por qué hay (Git) extraño y terrible número de 40 dígitos en hexadecimal?
Pero Git no estaba demás injustificadamente. Estas diferencias eran necesarias. Lo más probable, la gente piensa que Git es más complicado de lo que realmente es, simplemente porque vienen con otro bagaje de experiencia. CVS deja a fondo. Por el momento, probablemente, hay muchos programadores que nunca han usado CVS en sus vidas y que pueden encontrar es, cómo funciona CVS, muy confuso, simplemente porque han aprendido en el primer lugar de Git.
Podría acelerar el desarrollo del kernel de Linux para crecer con la velocidad existente sin Git? ¿Por qué?
Torvalds: Bueno, "sin git» - por supuesto. Pero habría proporcionado por el hecho de que alguien escriba un Git equivalente: algunos LES distribuida, lo que sería tan eficaz como, y Git. Sin duda, nos necesitábamos algo como Git.
¿Cuál es su opinión actual sobre GitHub?
Torvalds: Github es un recurso excepcional para la celebración; No tengo absolutamente nada en contra de él. Queja que tuve fue el hecho de que, como una plataforma de desarrollo GitHub - comete pull-rekvest, trazando la historia de los problemas y así sucesivamente - no está funcionando lo suficientemente bien. No es ni de lejos, no como para algo como el kernel de Linux. Demasiado limitado.
Esto es parte de cómo se desarrolla el núcleo Linux, pero en parte también porque las interfaces con GitHub fomentar activamente el mal comportamiento. Comete hizo en GitHub comentarios contienen estas confirmaciones, etc., simplemente porque la interfaz web en GitHub alentó activamente a la mala conducta. Lo arreglaron algunas de estas cosas, por lo que probablemente funciona mejor, pero nunca va a ser adecuado para algo como el kernel de Linux.
¿Cuál es el uso más interesante Git y / o GitHub que cumplen?
Torvalds: Estoy muy contento de que él (Git) para facilitar la puesta en marcha de nuevos proyectos. Hosting del proyecto anterior entregó mucho dolor, pero con la llegada de Git y Github hacen cualquier pequeño proyecto era tan fácil. No importa lo que el proyecto es, lo que importa es lo que puede hacer.
¿Tienes alguna proyectos paralelos "en el hoyo"? Algunos proyectos maravillosos que dominarán en el desarrollo de software para los próximos años?
Torvalds: No se prevé Nada. Pero yo lo haré saber si estos planes han cambiado.
ps: consejos y sugerencias son bienvenidos a transferir con el fin de mejorar la calidad de la traducción.
Fuente: geektimes.ru/post/248744/
Para conmemorar esta fecha, le pedimos a Linus para compartir la historia oculta de la creación de Git, nos dicen lo que piensa acerca de este proyecto y su impacto en el desarrollo de productos de software. Lo encontrarás en los comentarios a continuación el texto. Para esta entrevista las siguientes semanas, Git, en el que cada día vamos a considerar los proyectos individuales que utilizan el sistema de control de versiones. Esperar historias se desarrollan KVM, Qt, Drupal, Marioneta, vino, y muchos otros.
¿Por qué te prepara Git?
Torvalds: De hecho, yo nunca quise hacer el sistema de control de versiones (LES) y sentí que era justo lo menos interesante en el mundo de la informática (con la posible excepción de las bases de datos; ^) y yo apasionadamente odiado todos estos sistemas. Pero entonces llegó BitKiper (BK) y realmente cambiado la forma en que veía en el control de código fuente. BK hizo muchas cosas bien. Y la capacidad de mantener una copia local del repositorio y el código de combinación distribuida era una buena cosa. Una característica importante del modelo de control de versiones distribuido es que elimina uno de los problemas más graves de SLE - una política de quienes pueden hacer cambios. BK ha demostrado que se puede evitar simplemente distribuyendo todo repositorio. Pero BK tenía sus propios problemas; Varias soluciones técnicas conduce a un problema (cambio de nombre fue dolorosa), pero lo peor fue el hecho de que, dado que BK no se distribuye con el software de código abierto, y fue una gran cantidad de personas que no quieren usarlo. Así que terminamos que había varios desarrolladores importantes utilizando BK, que era libre para su uso en proyectos de código abierto, pero nunca llegó a ser generalmente aceptados. Así que es (VC) ha ayudado en el desarrollo del kernel, pero todavía sigue siendo momentos enfermos.
Se me ocurrió cuando Tridge (Andrew Tridgell) comenzó a la ingeniería inversa de un protocolo simple de BK, que era una violación de las normas de uso de BK. Pasé un par de semanas (meses? Así es como me sentí y) tratando de mediar entre el Tridge y Larry McVoy, pero con el tiempo se hizo evidente que simplemente no funciona. Así que, en algún momento, decidí que ya no puedo seguir utilizando BK, pero yo también no quiero volver a los peores días que eran antes de la BK. Es triste que si bien había otras herramientas para la LES, que hasta cierto punto trataron de utilizar un modelo de desarrollo distribuido, pero ninguno de ellos funcionó bien en el caso de uso a distancia. Yo tenía mis propios requisitos de desempeño, que son aproximadamente incluso no podía estar satisfecho con lo que estaba disponible; y yo también estoy preocupado por la integridad del código y el proceso de diseño, por lo que me decidí a escribir el suyo.
¿Cómo llegaste a esto? Usted escribió todo el fin de semana o simplemente la hora habitual?
Torvalds: Eh. Usted, por cierto, se puede ver cómo todo se tomó la forma de un repositorio Git código fuente, excepto para el primer día o algo así. El día fue dedicado a tratar de convertirse en un Git sí para hospedar para que pueda empezar a usar Git compromete en Git. Por lo tanto, el primer día o algo así, no está presente en la historia, pero todo lo demás - no. El trabajo principal se llevó a cabo principalmente durante el día, pero hay un par de discos y un par de medianoche - después de las dos de la mañana. Lo más interesante es la rapidez con que tomó la forma. La primera se comprometen en el Git árbol - no es un montón de código, pero sí lo básico - lo suficiente para cometer una de sí mismo. El truco no era tanto la codificación como para entender cómo Git tiene que organizar los datos.
Me gustaría hacer hincapié en que a pesar de que se ha recogido durante diez días o algo así (en el que hice mi primer git commit al repositorio del kernel de Linux), no fue de ninguna manera la codificación loco. El volumen de este código temprana es lo suficientemente pequeño, todo dependía de la aplicación correcta de las ideas básicas. Y así pasé algún tiempo "muele" antes del lanzamiento de la totalidad del proyecto. He visto los problemas de los demás. Vi lo que quería evitar.
Tanto si se aumenta (Git) para el nivel de sus expectativas? ¿Qué tan bien (Git) trabaja en sus estimaciones? ¿Hay alguna restricción?
Torvalds: Estoy muy contento con Git. Funciona excepcionalmente bien con el código del núcleo y seguir siendo mis expectativas. Lo que es interesante es el hecho de que haya tomado tanto muchos otros proyectos. Sorprendentemente rápidamente al final. Hay una gran cantidad de inercia en el cambio de uno a otro SLE; Basta con mirar el tiempo que se mantuvo en uso hasta CVS y RCS, pero en algún momento, Git y tomó su caso.
¿Qué piensa usted, ¿por qué es (Git) ha sido tan ampliamente adoptado en uso?
Torvalds: Creo que mucha gente se siente molesto por los mismos problemas que me hicieron odio LES. Y si bien había muchos proyectos en un intento de solucionar uno o dos pequeños problemas que sacar a la gente de sí mismos, de hecho no había nada como Git, que realmente ayudó a no tomar los grandes problemas en la cabeza. Incluso cuando la gente no entiende la importancia de un modelo de desarrollo distribuido (y muchas personas lucharon con esto), entonces tan pronto como se dieron cuenta de que permite realizar copias de seguridad más ligeras y fiables y permite que la gente haga su propio repositorio sin tener que pensar en la política en la resolución de grabación repositorio concreto, nunca miraron hacia atrás.
¿Será Git siempre existe o anticipar una revisión de LES en los próximos diez años? ¿Será usted uno de los que escribió?
Torvalds: No, voy a ser el uno para escribirla. Y tal vez veremos algo nuevo durante diez años, pero te garantizo que va a ser algo muy Git-como. No en el sentido de que en Git bien, pero en el sentido de que Git tiene las características básicas derecho dentro de esa otra LES nunca antes lo había hecho.
Sin falsa modestia;)
¿Por qué Git funciona tan bien en Linux?
Torvalds: Bueno, Git fue creado por nuestro trabajo, ya que es parte de ella. Ya he mencionado un modelo distribuido muchas veces, pero tiene sentido recordar una vez más la misma. Pero Git también se ha establecido para ser muy eficaz para un gran proyecto como Linux, y está escrito que ver lo que la gente considera un desafío antes del advenimiento de Git -. Porque estas son las cosas que hago todos los días
Así por ejemplo: el concepto de la fusión era visto como algo muy doloroso y difícil en muchos LES. Hubieras tenido que planificar su drenaje, porque eran un asunto serio. Esto no me está ustaivaet ya que suelo hacer decenas de fusiones en el día cuando estoy en una ventana de tiempo de la fusión, y aún así, la carga de trabajo no debe estar en la fusión, y el código de la prueba. La fusión en sí toma un par de segundos, es mucho más interesado en escribir para explicar la fusión.
Así, Git fue construido y escrito para mis necesidades. Y así sucede.
La gente decía que Git - sólo para la gente súper inteligentes. Incluso Andrew Morton (Andrew Morton) dijo que Git «Git diseñado para que se sienta aún más estúpido que antes". ¿Cuál sería su respuesta a eso?
Torvalds: Bueno, creo que fue en un primer momento, pero esto ya no es el caso. Hay varias razones por las que la gente se siente así, pero creo que eso es sólo una de las razones para quedarse. El que permanece, es muy simple: "usted puede hacerlo de diferentes maneras»
.
Usted puede hacer muchas cosas usando Git, y muchas de las reglas acerca de lo que debe hacer no proviene de las limitaciones técnicas, sino porque lo que funciona bien cuando tienes que interactuar con otras personas. Git es un potente conjunto de herramientas que pueden sobrecargar el principio, pero también significa que a menudo se pueden hacer las mismas o parecidas cosas de diferentes maneras y que todo funcionaba. En general, la mejor manera de aprender Git, probablemente, es simplemente hacer las cosas simples y ni siquiera mirar a otras cosas, siempre y cuando usted no está seguro con respecto a los conceptos básicos.
Hay varias razones históricas para la percepción de Git como una cosa compleja. Uno de ellos - el hecho de que era muy difícil. Aquellas personas que comenzaron a usar Git antes que nadie a trabajar con el núcleo Linux, realmente tuvieron que aprender a usar un juego bastante complicado de secuencias de comandos para que todo funcione. Todos los esfuerzos se orientaron a conseguir trabajar la tecnología de la base y un poco - de hecho, para hacer más fácil o evidente. Y Git, por supuesto, tenía una reputación que proporciona el conocimiento de lo que estaba haciendo antes. Sin embargo, era cierto en general durante los primeros seis meses o un año.
Otra razón por la que las personas se sentían como Git - una cosa complicada que Git es muy peculiar. Hay personas que disfrutan de las cosas tales como CVS durante una década o dos, y Git - no CVS. Ni siquiera similar. Diferentes conceptos. Equipos difieren. Git nunca trató de parecer como CVS, y viceversa. Y, si se ha utilizado el sistema similar a CVS, por mucho tiempo, da la impresión de complejidad y las diferencias sin causa Git. Las personas fueron rechazados los números de versión del sistema extraño. ¿Por qué el número de versión de Git «1.3.1», pero no tan bien hecho con un número creciente en las versiones de CVS? ¿Por qué hay (Git) extraño y terrible número de 40 dígitos en hexadecimal?
Pero Git no estaba demás injustificadamente. Estas diferencias eran necesarias. Lo más probable, la gente piensa que Git es más complicado de lo que realmente es, simplemente porque vienen con otro bagaje de experiencia. CVS deja a fondo. Por el momento, probablemente, hay muchos programadores que nunca han usado CVS en sus vidas y que pueden encontrar es, cómo funciona CVS, muy confuso, simplemente porque han aprendido en el primer lugar de Git.
Podría acelerar el desarrollo del kernel de Linux para crecer con la velocidad existente sin Git? ¿Por qué?
Torvalds: Bueno, "sin git» - por supuesto. Pero habría proporcionado por el hecho de que alguien escriba un Git equivalente: algunos LES distribuida, lo que sería tan eficaz como, y Git. Sin duda, nos necesitábamos algo como Git.
¿Cuál es su opinión actual sobre GitHub?
Torvalds: Github es un recurso excepcional para la celebración; No tengo absolutamente nada en contra de él. Queja que tuve fue el hecho de que, como una plataforma de desarrollo GitHub - comete pull-rekvest, trazando la historia de los problemas y así sucesivamente - no está funcionando lo suficientemente bien. No es ni de lejos, no como para algo como el kernel de Linux. Demasiado limitado.
Esto es parte de cómo se desarrolla el núcleo Linux, pero en parte también porque las interfaces con GitHub fomentar activamente el mal comportamiento. Comete hizo en GitHub comentarios contienen estas confirmaciones, etc., simplemente porque la interfaz web en GitHub alentó activamente a la mala conducta. Lo arreglaron algunas de estas cosas, por lo que probablemente funciona mejor, pero nunca va a ser adecuado para algo como el kernel de Linux.
¿Cuál es el uso más interesante Git y / o GitHub que cumplen?
Torvalds: Estoy muy contento de que él (Git) para facilitar la puesta en marcha de nuevos proyectos. Hosting del proyecto anterior entregó mucho dolor, pero con la llegada de Git y Github hacen cualquier pequeño proyecto era tan fácil. No importa lo que el proyecto es, lo que importa es lo que puede hacer.
¿Tienes alguna proyectos paralelos "en el hoyo"? Algunos proyectos maravillosos que dominarán en el desarrollo de software para los próximos años?
Torvalds: No se prevé Nada. Pero yo lo haré saber si estos planes han cambiado.
ps: consejos y sugerencias son bienvenidos a transferir con el fin de mejorar la calidad de la traducción.
Fuente: geektimes.ru/post/248744/
