Contexto

Mi equipo de 8 ingenieros está actualmente haciendo la transición a Git (de Subversion) para nuestra próxima gran novedad. Tenemos un puñado de ingenieros 'más experimentados' que están encontrando bastante difícil elegir Git. Me hacen las mismas preguntas triviales a pesar de haber proporcionado manuales de usuario, actividades de capacitación y sesiones de pizarra. Tuvimos dos consultores Junior que recogieron todo en pocos días y realmente iluminó el tema. Este no es un patrón que se limita a Git, pero como resultado se ha vuelto visible.

Pregunta

No me siento particularmente favorable para los ingenieros que no pueden / no aprenderán, especialmente el personal con los niveles de antigüedad que tenemos aquí. Sin embargo, sí quiero que el equipo tenga éxito y cree un gran producto. Estamos utilizando un modelo centralizado de Git Flow y siento que toda la nueva terminología los desconcierta.

¿Hay algo que pueda hacer para ayudar a estos empleados a aprender Git?

Sourcetree es el cliente que está siendo utilizado por todo el equipo.

Dales un juguete.

Git es duro. Especialmente si has estado haciendo control de fuente en un paradigma diferente. Rompí la compilación la primera vez que intenté trabajar con git. Me hizo tan paranoico que no quería registrarme hasta que todo estuviera hecho. Estaba escondiendo versiones en carpetas. Entonces finalmente descubrí lo que necesitaba para superarlo:

Necesitaba un lugar seguro para jugar.

Una vez que tuve eso, estaba causando problemas intencionalmente para poder aprender cómo solucionarlos, todo en mi lugar seguro. Desarrollé un patrón que podría usar aunque fuera interrumpido y aún así volver a estar en buen estado. En poco tiempo, la gente acudía a mí en busca de ayuda con git. Todo porque me tomé el tiempo para jugar con un juguete.

Si solo los arrojas al fondo, tendrás suerte si logran flotar.

El desarrollador promedio no necesita muchas golosinas de git. Es un sistema de control de fuente distribuido, pero la mayoría de los equipos lo usarán con un repositorio canónico central para empujar y tirar.

Los comandos principales que necesitará su equipo son:

• extraiga y combine los cambios desde el control remoto y maneje los conflictos resultantes (potencialmente rebase)
• commit y push commits a control remoto (o presione a repositorio / rama provisional para obtener los cambios en main después de la revisión)
• Para soporte: arregle el desorden después de hacer algo mal.

los que necesitarán los usuarios más avanzados son

• manejar compromisos locales
• administrar sucursales

Para las personas que no están familiarizadas con git y aquellos que no quieren aprenderlo, configure algunos comandos con alias rápidos para hacerlos y asegúrese de que todo sea correcto (agregue nuevos archivos, elimine archivos eliminados del repositorio, etc.)

Asegúrese de que estén bien documentados y sean decentemente a prueba de tontos.

Esto está en la línea del cómic xkcd , solo memorice los comandos y espere que las cosas no se desordenen demasiado, cuando le preguntan a un profesional.

Haga que usen una interfaz de usuario Git.

Si tienen experiencia con TortoiseSVN, TortoiseGit (solo Windows) funciona casi exactamente igual. De lo contrario, SourceTree (Windows + Mac) es maravilloso: tenemos múltiples QA que no son desarrolladores que han podido dominar fácilmente tareas complejas en Git gracias a SourceTree.

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.

Me gustaría referirlo a esta entrada de blog de Joel Spolsky .

La razón por la que está viendo que estos desarrolladores junior lo recogen rápidamente es muy probable porque no tienen una noción predeterminada sobre cómo funciona el control de versiones en general, o al menos no tienen un modelo mental tan profundamente arraigado. Como tal, entran con una pizarra limpia. Es probable que sus programadores de mayor antigüedad estén tratando de aplicar los conceptos que ya conocen, y están fallando como resultado de eso.

Además de esto, por mucho que no me guste decirlo; ¿Quién lee realmente los manuales de usuario? Por lo general, son muy malos para explicar el uso básico. Solo mire la página de confirmación de git del manual y considere cuántos términos y frases nuevos se están introduciendo a alguien que no está al día con el concepto. Sin una buena introducción, probablemente habría renunciado a usar Git allí mismo.

Mi consejo personal sería comenzar a explicar los comandos:

• git add <archivos>
• git commit
• git pull
• git push
• estado git

Los conflictos de fusión lógica deben explicarse a continuación, porque definitivamente ese será su primer problema una vez que las personas aprendan a confirmar el código.

Por lo general, surgirán situaciones en las que las personas necesitarán invertir más tiempo en cosas de aprendizaje (reversiones, etiquetas, conflictos de fusión, ramas, rebases, ganchos), pero tratar de explicar todo esto antes de que sea necesario no ayudará a las personas que tienen problemas para entrar el flujo.

Para concluir: desde mi experiencia personal, algunas personas simplemente no pasan tanto tiempo explorando nuevas técnicas, conceptos o herramientas y, por lo general, tienden a aprender cosas que les presentas a un ritmo más lento. Esto no significa que sean malos programadores o malas personas, pero generalmente tienen un conjunto de habilidades más limitado.

Git es un replanteamiento importante si aprendió a hacer el control de fuente en SVN. Muchos de los hábitos que desarrolló allí (que pueden haber sido la mejor práctica para SVN) lo desviarán cuando use git. Esto se debe principalmente a que el modelo de ramificación de git es fundamentalmente diferente. No aprovecha las carpetas para las ramas, y también es posible hacerlo no lineal porque fue diseñado para admitir mejor los casos de uso distribuidos. Lleva algún tiempo desaprender los hábitos de SVN y comprender cómo se supone que debes usar git.

Comience simple

Dice que ha elegido Gitflow como su estándar para la gestión de sucursales. Esto me parece tu mayor error.

Para citar a Gitflow considerado perjudicial :

Todas estas ramas que se usan obligan a GitFlow a tener un complejo conjunto de reglas complicadas que describen cómo interactúan. Estas reglas, junto con el historial intangible, hacen que el uso diario de GitFlow sea muy difícil para los desarrolladores.

¿Puedes adivinar qué sucede cada vez que configuras una red compleja de reglas como esa? Así es, las personas cometen errores y los rompen por accidente. En el caso de GitFlow, esto sucede todo el tiempo. Aquí hay una lista breve, de ninguna manera exhaustiva, de los errores más comunes que he observado. Estos se repiten constantemente, a veces todos los días, a menudo una y otra vez por los mismos desarrolladores, que en la mayoría de los casos son muy competentes en otras áreas de software.

Sus desarrolladores probablemente estén abrumados por la gran complejidad de este estándar. Personalmente no creo que tenga ningún beneficio, y el artículo anterior presenta el mismo argumento. Pero esa es una discusión separada. Sin embargo, objetivamente, es un estándar bastante pesado con mucho manejo manual, y requiere mucho esfuerzo cognitivo.

Necesitas comenzar más simple. No se preocupe por un estándar de ramificación en este momento. Concéntrate en acostumbrarlos a usar git primero. Realmente solo necesita algunas operaciones para comenzar:

• clon
• Halar
• rama
• unir
• cometer
• empujar
• conocimiento sobre cómo .gitignorefunciona
• tal vez etiqueta

Sí, su historia puede parecer un poco desordenada al principio. Esto está bien. No te preocupes por eso ahora. Solo consíguelos usando git .

Incremente gradualmente el conocimiento

A partir de aquí, puede educarlos gradualmente sobre el uso un poco más avanzado.

• Enséñales el comando de alijo épico
• Enséñeles cómo usar reset cuando quieren deshacerse del commit local que acaban de hacer
• Enséñeles a enmendar
• Enséñeles cómo cambiar la base para evitar compromisos de fusión innecesarios
• Enséñeles cómo rebasar interactivamente para organizar sus compromisos antes de presionar
• Enséñeles cómo pueden pagar desde cualquier hash, etiqueta o rama

Especialmente asegúrate de aprovechar las oportunidades para mostrarles formas más limpias de introducir su código en el repositorio, pero también enseña esto en las actividades de capacitación y lo que tienes. Tener un gurú o dos al que las personas puedan acercarse cuando no estén seguras de qué hacer también ayudará mucho. Si tiene algo como Slack, cree un canal dedicado y anime a las personas a hacer y responder preguntas allí.

Luego elija un estándar de ramificación

Una vez que tenga la mayor parte de la empresa competentes en el uso de git en absoluto, a continuación, se puede ver en las normas de ramificación. Elegir uno por adelantado es una muy mala idea por múltiples razones:

• No tienen suficiente conocimiento de la herramienta para decirle si el estándar funciona bien para los casos de uso de la compañía.
• No podrán ofrecer estándares alternativos
• Tienen que aprender tanto la herramienta como el estándar al mismo tiempo.
• Algunos supondrán que el estándar que eliges es la única forma en que pueden usar git
• No podrán identificar casos extremos raros donde el estándar está haciendo más daño que bien

No deberías estar transmitiendo un flujo de trabajo Git desde la montaña. Su equipo necesita tener aportes al respecto y poder darle retroalimentación sobre si va bien o no. No pueden hacer esto si aún no comprenden los fundamentos. No necesita que cada desarrollador tenga un conocimiento profundo como este, pero definitivamente necesita varios que realmente lo entiendan. Y necesita que la gran mayoría sea al menos competente en git para que sepan lo suficiente como para mantenerse un poco en los rieles.

Aquí hay un par de alternativas a Gitflow que su equipo puede considerar:

• OneFlow
• Flujo de trabajo de rama característica
• Flujo de trabajo centralizado

Míralos a ellos y a Gitflow, compáralos con tus casos de uso y elige uno que se ajuste.

Encontré stackoverflow muy útil mientras estaba aprendiendo la terminología de Git. Preguntas como estas fueron realmente útiles para mí (principalmente debido a su concisión) y las mantuve abiertas en pestañas durante las primeras dos semanas que lo usé. ¿Quizás imprimir un par de respuestas en negrita? Especialmente el diagrama del primero.

¿Cuáles son las diferencias entre "git commit" y "git push"?

¿Cuál es la diferencia entre 'git pull' y 'git fetch'?

También encontré que una representación visual del tronco es increíblemente útil, pero ya la estás cubriendo con SourceTree.

_{Aparte, esta parte probablemente pertenece a un comentario, pero me falta el representante: soy uno de los consultores junior mencionados en la pregunta. Antes de comenzar, tenía una idea de lo que era un sistema de control de fuente y había tocado SVN literalmente dos veces, Gusdor me da más crédito del que merezco. Todo el equipo tenía entrenamiento especializado de Git de alta calidad, juguetes y tiempo para jugar. El problema no es con las instrucciones de Gusdor. Espero que haya una buena solución alternativa para esto, así puedo marcarlo con fuerza y ​​aprender más.}

Comprarles un libro

Honestamente, me caí de lleno en el campamento que describe. Vengo de un fondo de SourceSafe y ClearCase. Al principio, Git era completamente inescrutable para mí, a pesar de que mi jefe lo atravesó varias veces.

Lo que me ayudó fue un libro que describía claramente lo que estaba sucediendo, pero lo más importante, cómo Git era fundamentalmente diferente de cualquier sistema de control de fuente que había usado antes. Ahora, prefiero Git sobre cualquier otra opción.

Desafortunadamente, no puedo recordar qué libro había leído en ese momento, pero solo asegúrate de que el libro que obtengas para ellos (o los señales) se centre en cómo es diferente y cómo requiere una mentalidad diferente.

La mejor suposición para una recomendación de libro es:

Pro Git de Scott Chacon (enlace de Amazon para facilitar ... compre a quien quiera: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Nota : No , no comprar un libro de referencia para Git. Eso no ayudará en absoluto.

Desde mi experiencia, algunas personas pueden sentirse cómodas usando git sin entenderlo. Encuentran tutoriales básicos, recogen comandos básicos y están listos para comenzar. Probablemente ahí es donde encajan los consultores junior. ¡No creo que realmente puedas aprender git en pocos días!

Otras personas, no pueden hacerlo, necesitan entender qué está haciendo git, y eso lleva más tiempo. Estaba en esa categoría; Me pareció muy útil jugar con el contenido del .gitdirectorio, fue entonces cuando las cosas comenzaron a hacer clic para mí. También ayudaron sesiones individuales con nuestro líder tecnológico.

Puede hacer tutoriales uno a uno porque las personas aprenden de manera diferente y pueden estar realmente confundidos acerca de las diferentes partes, en una sesión uno a uno es más fácil de ver y resolver. Si realmente les molesta el hecho de que no entienden cómo git realiza un seguimiento de las ramas, muéstreles el contenido del .gitdirectorio, etc.

Estoy jugando con la introducción de gitdónde estoy (de TFS), por lo que su pregunta es oportuna para mí, especialmente porque también he tenido un poco de retroceso al abordar el tema.

En Peopleware , las tesis subyacentes de todo el libro son:

Los principales problemas de nuestro trabajo no son tanto tecnológica como sociológico en la naturaleza .

Menciono esto porque el nuestro no es un problema técnico. git, aunque un poco obtuso, probablemente no esté más allá de la capacidad de los tuyos o de mis desarrolladores principales, a menos que sean extremadamente estúpidos *.

Veámoslo desde el punto de vista de sus desarrolladores, como personas, no como máquinas técnicas:

Les está pidiendo que dejen de usar un sistema de control de fuente del que tienen (probablemente) dominio, a uno que no tienen. Es un poco como pedirle a un gitexperto que deje de usarlo gity se mude svn, ¿no? Creo que la experta en git estaría molesta, y probablemente no se esforzará demasiado svnporque gitfunciona bien y hay partes en las que realmente le gusta que son realmente difíciles de hacer svn.

Esa es probablemente la razón por la cual los juniors lo han aprovechado mejor, tal vez no se han acostumbrado svny gites su oportunidad de deshacerse de él ^.

Sin embargo, las personas mayores desconfían del costo de oportunidad ; si aprenden git, entonces no son:

• Learning React / Angular / Swift / Blockchain / Kotlin (algo que sienten que deberían estar aprendiendo).
• Haciendo bricolaje / tallado / navegación / poesía / glockenspiel / cualquier otra cosa que realmente quieran hacer.
• Pasar tiempo con sus hijos / parientes / amigos / personas significativas.

• Entregando esta "gran cosa nueva": hay una fecha límite, un presupuesto, etc. Probablemente estén preocupados por eso.

  "Necesito hacer todo lo anterior, ¿por qué tengo que usarlo git cuando ya tenemos el control de la fuente?"

¿Qué razones les has dado para cambiar de una cosa en la que son buenos, a otra que es francamente incómoda cuando eres nuevo en ella y requiere un replanteamiento completo de cómo te va? ¿Has explicado los beneficios de las gitfunciones?

Solicitudes de extracción? Checkins de grano fino? Fuente distribuida? ¿Tenedores?

¿Han traído a estas razones? Estos son cambios masivos y estructurales si se encuentra en una mentalidad de control de fuente centralizada, no solo cambios técnicos sino también culturales, y sabemos lo difícil que es cambiar una cultura.

Básicamente, piense qué es lo que le está pidiendo a sus desarrolladores que hagan y asegúrese de que sea por las razones correctas. Si solo quieres hacerlo porque svnes estúpido y viejo y ya nadie lo usa, entonces está bien, pero eso es más difícil de vender a otros que no piensan como tú y solo quieren aprovechar su día. Debe indicar los beneficios en términos que tengan sentido para su equipo y para el proyecto. Si puede lograr que acepten que gitvale la pena, entonces no tiene que preocuparse de que aprendan la tecnología, simplemente acepte el flujo de trabajo que haya configurado.

Buena suerte.

Creo que esto es menos una pregunta de ingeniería de software y más una pregunta de psicología. Me gustaría hacer referencia a Algorithms to Live By: The Computer Science of Humand Decisions. En él, el autor aborda el tema de la compensación de exploración / explotación. Los humanos generalmente pasan por una fase de exploración y luego por una fase de explotación (uso) de lo que han explorado. Hay una teoría matemática sólida detrás de por qué este es el caso para obtener un uso óptimo de algo en un cierto intervalo.

Esto también se extiende a la edad y la experiencia. Los humanos ven sus propias vidas como un intervalo, y después de una cierta fase de exploración, es óptimo comenzar a usar su conocimiento. Citaron un estudio en el que se les preguntó a los participantes mayores si querían conocer a alguien famoso que les gustara o, más bien, a un miembro de la familia. Por lo general, eligieron al miembro de la familia, mientras que las personas más jóvenes eligieron a la persona famosa con mayor probabilidad. Sin embargo, cuando se les pidió que imaginaran cómo decidirían si fueran 20 años más jóvenes, las personas mayores también eligieron habitualmente a la persona famosa. Lo que sugiere que las personas dejan de construir sus redes sociales cuando creen que tienen menos de la exploración que de explotar lo que ya saben.

Sus ingenieros superiores probablemente sean mayores, probablemente hayan pasado por algunos sistemas de control de versiones. SVNes probablemente el mejor que han usado hasta ahora (al menos mirando los sistemas de versiones anteriores que usé, SVN los superó a todos).

Su estrategia óptima es explotar SVN, porque han explorado y han descubierto que es lo mejor, que explotan ahora.

Esta es la psicología humana básica y cientos de miles de años de optimización evolutiva contra la que luchas.

Tendrá que mostrarles a) cuánto tiempo tienen una carrera por delante, prepararlos para pensar desde una perspectiva diferente sobre el intervalo en el que se ven yb) preguntarles qué creen que es genial y qué piensan ' re desaparecidos en SVN. Puede presentar cientos de beneficios git, pero ya tendrán una idea clara de por qué SVNes el mejor, después de todo, probablemente experimentaron 5 sistemas de control de versiones antes. Necesitas encontrar la grieta en la armadura de ese argumento, y luego ver si gitpuedes resolver estos problemas, entonces se habrán convencido.

No les des una herramienta o una GUI para usar Git. Solo confundirá las cosas. Git fue concebido para ejecutarse en una línea de comando, por lo que probablemente debería ser el lugar donde se aprende. Cualquier GUI puede venir con sus propios términos y peculiaridades, seguir con lo que es simple.

Lo siguiente sería analizar algunos de los problemas que Git hace mejor que SVN. Para que su equipo lo aprenda, debe motivarlos a ver por qué git es mejor.

• Capacidad para comprometerse mientras no está conectado a la red
• Posibilidad de hacer y jugar con sus propias ramas.
• Parches que pueden enviarse entre sí y aun así fusionar pistas
• Recolección de cerezas sin dolor.
• cambios de rebase
• encontrar errores con git splice

Estoy seguro de que SVN ha avanzado en los últimos años, pero solían ser cosas que causarían un mundo de dolor. Si los desarrolladores ven que esta nueva herramienta no es solo algo elegante, sino que tiene ventajas sólidas para su trabajo, es más probable que la respalden.

Es algo nuevo que aprender y hay suficientes similitudes que pueden ser confusas, pero realmente en 2017 DCVS es prácticamente una habilidad esencial para cada desarrollador.

Diles que no se preocupen

En Git, una vez que se compromete el trabajo, es casi imposible perder. El único trabajo que puede perder fácilmente es el trabajo que aún no se ha comprometido.

Muéstrales cómo git reflogfunciona. No tienen que saber cómo usarlo; solo necesitan saber que está allí, para que puedan obtener ayuda para recuperar su trabajo si algo sale mal.

Luego, infórmeles esta regla simple: cuando tenga dudas, comprométase. Siempre pueden retroceder la confirmación más tarde (¡incluso desde el control remoto!).

No uses una GUI

Una GUI les dará un comienzo más rápido, pero nunca entenderán realmente a Git. Por otra parte, he encontrado que es no "casi imposible perder" trabajo comprometido cuando se utiliza una interfaz gráfica de usuario de Git. He visto que las GUI hacen cosas horribles como presentar una lista de verificación al fusionar y luego, si el usuario desmarca un elemento, borra ese archivo del historial sin advertencia ni registro de él. Una GUI es mucho peor que simplemente aprender Git de línea de comandos.

Par de confirmaciones de código de programa

El aprendizaje git add -Aseguido git commitno debería ser demasiado difícil, pero particularmente cuando se fusionan (o rebase) contra el control remoto, necesitarán ayuda. Deje en claro que cualquiera puede pedir ayuda en cualquier momento. Espere mientras escriben los comandos y toman notas. Con el tiempo, aumentarán gradualmente la cantidad de situaciones que pueden manejar sin ayuda.

Git ya está a salvo

Alguien arriba habló sobre tener "un lugar seguro para jugar". Pero Git es ese lugar seguro. Solo hay dos casos normales y cotidianos en los que es fácil perder el trabajo:

• Código no comprometido
• Usando una GUI

Asegúrese de que se comprometan temprano y con frecuencia, y que no comiencen por el camino equivocado con una GUI, y pronto verán que pueden confiar en Git con su código incluso más que otros sistemas de control de origen en el pasado.

Yo recomendaría echar un vistazo a Gitless . Es una envoltura sobre git que simplifica mucho el flujo de trabajo básico (no es necesario preocuparse por un área de preparación, las sucursales mantienen sus propias copias de trabajo de los archivos, git rebasese manejan los usos más simples gl fuse, etc.) mientras se mantiene un repositorio de git subyacente para la colaboración o si necesitas hacer algo inusual. Además, los mensajes son un poco más amigables para los novatos. Y los comandos están lo suficientemente cerca como para que git actúe como un trampolín si necesitan usar un sistema sin gitless por cualquier razón.

Intenté documentar los conceptos básicos de cómo usar la línea de comando de git. Todavía era confuso, tanto para mí (que tenía experiencia en el uso de Perforce y Source Safe) como para los programadores que preferían el viejo paradigma de "simplemente comprimir las carpetas relevantes". Era preocupante que una herramienta opaca modificara el contenido de mi directorio de trabajo y, a menudo, tuviera que discutir con la herramienta para incorporar cambios particulares en mi directorio de trabajo.

En cambio, uso dos tipos de indirección.

• Uso GitKraken para proporcionar un historial visual de mis ramas y una GUI que oculta las instrucciones de la línea de comandos. GitKraken maneja las interacciones entre el repositorio remoto "origen" y lo que git piensa es mi directorio de trabajo local.

• También mantengo un directorio de trabajo local "real" que está separado de lo que git piensa que es mi directorio de trabajo local. Sincronizo manualmente estos dos directorios de trabajo, lo que me permite estar mucho más cómodo de que cualquier cambio en mi directorio de trabajo sea lo que pretendía tener.

¿Hay algo que pueda hacer para ayudar a estos empleados a aprender Git?

¿Estás seguro de que el problema es Git y no otra cosa? Lo que obtengo del comentario es que la gerencia decidió cambiar algo sin obtener la aceptación de los contribuyentes principales y le está encomendando a alguien menor que lo impulse. Ese parece ser un buen punto de partida para el fracaso, cualquiera que sea el cambio. La complejidad de Git no es un problema, el problema es que se les impone un cambio por el que no sienten la necesidad.

Por lo tanto, no se concentre en cómo enseñarles Git, siempre que no vean una ventaja para el interruptor, arrastrarán los pies. Muéstreles cómo Git es una solución a los problemas que tienen ahora. No cómo Git puede proporcionarles cosas que todavía no sienten la necesidad, no cómo Git brinda una solución a los problemas de otras personas, cómo Git resuelve los problemas que están enfrentando ahora. Entonces enseñarles Git no será un problema.

A menudo, Git se utiliza en una empresa para resolver problemas con sucursales. Sí, es mejor en las ramas que Subversion, pero no hace ninguna magia.

Es muy probable que los desarrolladores experimentados tengan trabajo en muchas empresas que lo hayan hecho.

• Se crearon sucursales ya que la gerencia no está dispuesta a decidir entre demandas conflictivas
• Ha utilizado una rama para cada cliente en lugar de conmutadores de configuración.
• He tenido que tener una rama de corrección de errores para cada cliente ya que la gerencia no estaba dispuesta a hacer que todos los clientes se actualicen a la misma versión del software
• Etc.

Por lo tanto, tan pronto como algunos me dicen que una herramienta es buena para ramificar, mi mente me dice.

La gerencia no quiere decidir en qué dirección va la empresa, y preferiría que desperdiciara la vida teniendo que fusionar mi trabajo en 101 ramas diferentes, además de tener que probar 101 versiones diferentes del software.

Además, el concepto de que dos personas estarían trabajando en el mismo archivo al mismo tiempo es "bueno", simplemente no es aceptable para alguien que ha experimentado un proyecto bien administrado, por lo tanto, promover Git como herramienta para hacerlo, es poco probable que tenga experiencia desarrolladores que te gustan.

Cada vez que miro el historial en Git, es muy difícil ver por qué se modificó el código, ya que el 50% o más del historial se fusiona y, lógicamente, nunca debería haber sido público y dejan de tener sentido tan pronto como el código deja a los desarrolladores máquina.

Pero me encantaría trabajar en algún lugar donde:

• Ningún código ingresa al sistema central hasta que se haya compilado y probado la unidad en un servidor de confianza.
• Hay una manera fácil de rastrear revisiones de código
• Donde cada vez que hago un "get", el código siempre se compila y funciona
• Donde puedo impulsar mis cambios sin tener que tener una carrera con otra persona, o tener que desviarme en la oficina para ver si he roto la construcción.

Así que resuelva los problemas reales y si Git es parte de las soluciones que sus desarrolladores experimentados comprarán, pero no espere que les guste Git solo porque es un juguete genial que puede hacer "fusiones mágicas".

Por lo tanto, cualquier lugar que permita que un desarrollador empuje desde su Git local al Git central lo está haciendo mal, un proceso automatizado controlado debería tomar los cambios de los desarrolladores y después de probarlos, etc., y verificar que las fusiones estén bien actualizando el Git central. sucursales, etc. que no son de interés a largo plazo.

Espero que Kiln ( http://www.fogcreek.com/fogbugz/devhub ) o incluso GitHub que use un flujo de trabajo de "solicitud de extracción" mantenga contentos a los desarrolladores experimentados, por ejemplo, no comience con el nivel bajo, comience con el mejorado proceso.