Esta respuesta intenta abordar cómo interesar a los programadores senior git, no sobre cómo aprender de gitla manera más rápida; para eso, el excelente libro de git es excelente o cualquier cantidad de tutoriales (=> Google). Los buenos enlaces para ir con esta respuesta son Git es una estructura de datos puramente funcional o especialmente el corto Cómo almacena sus datos git .
Me temo que tengo una visión bastante sombría sobre esto. He estado exactamente en tus zapatos: soy un gitnerd y quería transformar un equipo lejos de svn, seamos sinceros, resultados minúsculos. En mi caso, me ha llevado a cambiar activamente mi propia percepción y a aceptar que las personas simplemente no pueden ser "forzadas a la felicidad". Las personas no son computadoras, es increíblemente difícil programarlas. Todavía estoy feliz por haberlo intentado, me ha mostrado de manera bastante suave lo que hago y lo que no quiero hacer en mi vida profesional.
Hay personas que comienzan a motivarse cuando hay cosas nuevas involucradas, y hay quienes están desmotivados. Esto no tiene nada que ver git, pero gitespecíficamente siempre tiene el efecto de "¿por qué deberíamos usarlo si svnestá bien?", Que es una barrera psicológica masiva.
Además, realmente el grokking gitrequiere un intenso interés en las estructuras de datos abstractos. Puede sonar increíble, pero en mi experiencia hay programadores que no tienen ningún interés en eso y que están aburridos y agobiados por elementos más complejos que las matrices simples. Puede discutir una y otra vez si deberían estar haciendo el trabajo que están haciendo, pero es lo que es.
Si a la gente no le interesa, no lo entenderán. Llano y simple. Apostaría a que el desinterés es la razón principal de las malas calificaciones en la escuela, sin perder inteligencia.
Dicho esto, aquí habría un plan de estudios tal como lo aplicaría, basado en la acumulación de conocimiento de abajo hacia arriba. No me ha funcionado, pero puedes tomarlo como inspiración para rodar el tuyo.
GUI
Si bien el siguiente enfoque no necesariamente necesita soporte de GUI para las acciones ( git adden un repositorio hello world ...), ayuda enormemente tener una GUI para visualizar el repositorio, desde el principio. Si no puede decidir cuál usar, tome gitkcomo último recurso. Si sus chicos usan algún tipo de editor visual, busquen su gitcomponente GUI.
La estructura de datos (estática) es clave
Comience explicando los tipos de datos internos (solo hay tres más uno de ellos: blobs, árboles, commits, etiquetas anotadas, la última de las cuales no es de ninguna importancia en esta etapa) y su estructura. Puede hacerlo fácilmente en la pizarra / con un lápiz; el árbol es fácil de dibujar ya que nunca se puede cambiar, literalmente puedes agregar cosas todo el tiempo. Puede hacer una sesión de juego en un repositorio local recién creado y usar git cat-filepara mirar los objetos reales para mostrarles que, de hecho , son tan triviales como se anuncian.
Si puedes ayudarlos a entender eso
- ... hay literalmente solo 3 tipos de objetos en la historia, todos muy simples, casi triviales, y
- ... la mayoría de los
gitsubcomandos simplemente "masajean" esos objetos de una forma u otra, con operaciones casi triviales (básicamente, solo hay uno: agregar una nueva confirmación en alguna parte), y ...
- ... todo se puede ver fácilmente frente a ti con
lsy git cat-file...
entonces tendrán la traducción mental de lo que realmente está en el repositorio. En este punto, los señores pueden recordar que las partes internas de svnla magia arcana (¿alguna vez tuvieron problemas con las cerraduras dentro del repositorio svn, o con ramas "reintegradas" y tal?), Y esto puede motivarlos un poco.
Un problema, específicamente con las personas acostumbradas svn, es acostumbrarse a la idea de que un commit (el objeto, no la acción) siempre es el árbol de directorios completo. En svn, las personas se utilizan para confirmar archivos individuales. Es un enfoque radicalmente diferente. Ah, y el hecho de que el mismo término "commit" se use tanto para un objeto estático como para una acción tampoco ayuda.
El otro problema para los svnhombres es que svnusa una historia lineal, no un árbol. Esto es, nuevamente, muy diferente. Así que este es el momento de señalar muchas de estas diferencias .
Acciones explicadas en términos de la estructura.
Cuando hayan entendido de qué partes gitestá hecho un repositorio, es hora de mostrarles exactamente qué hacen los gitsubcomandos individuales en términos de esos.
Estoy hablando de add, commitjunto con el directorio de trabajo local y la etapa (asegúrese de que entiendan que el directorio de trabajo no es el mismo que el área de preparación, que no es lo mismo que el repositorio).
Cuando hayan entendido que estos comandos simplemente hacen crecer el árbol (que, nuevamente, en esta etapa, consiste en 3 de los tipos: blobs, árboles, commits, no solo commits), ¡puedes hacer un primero git pushy git pull(en modo de avance rápido! ) para mostrarles que gitliteralmente solo está empujando sus objetos, que los hashes son realmente solo hashes de contenido, que puede copiar fácilmente estas cosas con un comando de copia del sistema de archivos, etc.
Obviamente, manténgase alejado de las opciones no esenciales de esos comandos, estamos hablando git add hello.txtaquí.
Ramas
Tenga en cuenta que la ramificación es especialmente difícil para las svnpersonas, ya que es totalmente diferente. El svnmodelo es mucho más fácil de visualizar, ya que básicamente no hay nada que visualizar, está a la vista. El gitmodelo no tanto. Asegúrese desde el principio de que sepan que las ramas y las etiquetas son solo "notas adhesivas" que apuntan a alguna parte, y que en realidad no "existen" en términos de la historia estática e inmutable.
Luego, haga un ejemplo tras otro para mostrar lo que realmente puede hacer con ellos. Como usted mismo parece estar acostumbrado git, no debería tener problemas para encontrar motivación allí. Asegúrese de que siempre vean esto en términos de cómo crece el árbol.
Si tienen eso abajo, puedes explicar cómo git pulles realmente git fetch && git merge; cómo todos los repositorios contienen exactamente los mismos objetos ( git fetches casi lo mismo que copiar cosas scpdentro del directorio de objetos git) y así sucesivamente.
Probablemente, si en este momento no ha llegado para despertar su interés, entonces también puede darse por vencido, pero si logran llegar tan lejos, entonces tienen todas las herramientas mentales a su disposición, y debería haber poco miedo involucrado más. El resto (flujo de trabajo de git ...) debería estar cuesta abajo entonces.
Ultimas palabras
Esto suena como un gran esfuerzo, y realmente lo es. No venda esto como "necesitamos esto para este proyecto" sino "esto lo ayuda personalmente a desarrollarse y lo ayudará en todas sus futuras interacciones". Necesitas mucho tiempo para esto, y el tiempo es dinero. Si no tiene la aceptación de la gerencia en esto, puede que no valga la pena; tal vez deberías hablarlo con tu jefe.
Si decide dejar de enseñar a los desarrolladores que aparentemente no son capaces de comprenderlo, pero que absolutamente debe usar giten el futuro, considere reemplazar toda interacción con gitcomandos por scripts cocinados o alguna GUI que elimine todos los gitdetalles. Vierta todo el control de errores, etc. en los scripts e intente que funcione.