¿Debo esperar que mi equipo tenga más que una competencia básica con nuestro sistema de control de fuente?

Mi empresa cambió de Subversion a Git hace unos tres meses. Teníamos semanas de aviso previo antes del cambio. Como nunca antes había usado Git (o cualquier otro DVCS), leí Pro Git y pasé un poco de tiempo haciendo girar mis propios repositorios y jugando, de modo que cuando nos cambiamos podría seguir trabajando con un dolor mínimo. Ahora soy el 'chico Git' por defecto.

Con un par de excepciones, la mayoría de mi equipo todavía no tiene idea de cómo funciona Git. Por ejemplo, todavía piensan en las ramas como copias completas del código fuente, e incluso llegan a clonar el repositorio en varias carpetas (una por rama). En general, ven a Git como una caja negra aterradora.

Dada la naturaleza fundamental del control de la fuente en nuestro trabajo diario (sin mencionar la cantidad ridícula de poder que Git nos brinda), soy de la opinión de que cualquier desarrollador que no logre cierto nivel de competencia con él es una responsabilidad .

¿Debería esperar que mi equipo comprenda al menos algo de cómo funciona Git internamente y cómo usarlo más allá de las operaciones más básicas de extracción / fusión / inserción? ¿O simplemente estoy haciendo algo de la nada?

El profesionalismo dictaría naturalmente que un desarrollador se familiarice con las herramientas estándar de su equipo, incluso si son nuevas y desconocidas (o incluso no deseadas).

Sin embargo, algunas cosas en tu publicación me dan pausa.

Teníamos semanas de aviso previo antes del cambio.

¿Semanas? Cambiar el control de fuente es un gran problema. Debería haber habido meses de aviso previos a un cambio como ese.

Con un par de excepciones, la mayoría de mi equipo todavía no tiene idea de cómo funciona Git.

Entonces, ¿su empresa cambió a un sistema de control de fuente que pocos, si alguien, entendieron en ese momento?

A menos que haya algún otro contexto, parece que todo el movimiento fue mal pensado (el movimiento, no la elección, soy un gran fanático de git).

Hemos estado presentando a Git donde trabajo y, naturalmente, ha habido resistencia. Fue para un nuevo proyecto, por lo que ahora mantenemos dos repositorios.

Parte del problema es que las personas no verán los beneficios de cambiar a un SCM diferente cuando el que han estado utilizando les funcione. Ayudó cuando nos sentamos con nuestro equipo para un par de sesiones de una hora en las que mostramos casos de uso de nuestros proyectos y cómo Git lo hizo más fácil. Por ejemplo, las cosas que nos ayudaron:

• Sucursales locales para fomentar la experimentación
• Git bisect para localizar fácilmente errores
• compromisos frecuentes sin interrumpir a otros
• Cambio rápido entre sucursales

etc. Cada uno de estos resolvió un problema que habíamos encontrado con nuestro SCM anterior y que la gente pudiera apreciar más a Git.

La otra cosa es que no se puede esperar que la gente se vaya y lea libros al respecto porque muy pocos lo harán. Tal vez necesiten hacer el trabajo, tener otras responsabilidades o cualquier número de razones.

Entonces, como 'Git expert', debe sentarse y hacer que sea lo más fácil posible para las personas usarlo. Quieren estar escribiendo código, no jugando con su sistema SCM.

La CLI de Git es críptica y los problemas triviales (para usted y para mí) impedirán que las personas trabajen. Esto es lo que sucedió en nuestro equipo (ten en cuenta que estos son desarrolladores bastante competentes):

• Git con SSH en Windows era un problema común.
• La gente tiraría, fusionaría, pero no empujaría la fusión. Entonces el gráfico sería un gran desastre confuso
• El problema de rendimiento en Windows hizo que el "estado de git" tomara 15 segundos
• No se pudo encontrar la manera de obtener una nueva rama. Harían un "git checkout -b" que se ramificaría de lo que sea que estuvieran trabajando
• EGit en eclipse tenía un menú abrumador. Terminé diciéndole a todos que usen la línea de comando al principio
• Basado en el elemento anterior, fusionando y configurando git mergetool
• Confundido sobre las diferencias entre "git add" y "git commit" y "git push".

Todavía tenemos algo de resistencia, pero la gente definitivamente puede ver los beneficios. Es vital contar con algunas personas Git para recibir orientación y estar dispuestos a ayudar. También evitaría enseñar cosas interesantes como restablecer / rebase / - enmendar / etc. Debido a que la mayoría de las personas usarán Git como SVN, es mejor dejar que lo descubran si así lo desean.

Competente vs Git-mania

Un término como competencia básica puede significar cosas diferentes para diferentes personas. Mucha gente parece tener git-mania (no es que haya nada de malo en eso). Muchos de nosotros hemos sido quemados realmente por la negligencia propia y ajena con el control de la fuente.

Por qué es importante (tanto)

Las herramientas de control de fuente son críticas porque el mal uso puede retrasar no solo a una persona, sino a todo un equipo. El mal uso de Git debería ser menos problemático que el mal uso de SVN, CVS y otros sistemas. Históricamente, el uso inepto de sistemas que bloqueaban archivos era particularmente problemático, y las compañías contrataban equipos de construcción discretos para que cuando alguien se metiera en problemas, hubiera un experto fluido que no hiciera más que controlar el origen que pudiera curar la herida en el repositorio. Esto explica parcialmente parte de la pasión que encuentras detrás de git.

¿Cómo se ve la competencia básica?

Algunos criterios concretos incluyen:

• Sin referencia a la documentación:

  • Puede agregar archivos, confirmar cambios, actualizaciones push y pull.
  • Puede ver el estado y la actividad de revisión.
  • Puede ramificarse y fusionarse rápidamente y sin introducir errores.
  • Puede usar el pago de forma adecuada.
  • Cree comentarios de confirmación que cumplan con los criterios de comentarios del grupo.
  • Diferencia de cambios entre copia de trabajo y archivo.

• Con documentación:

  • Agregue usuarios y credenciales para el repositorio local.
  • iniciar un repositorio local.
  • Administrar repositorio remoto.
  • Configure archivos ignorados, genere pares de claves públicas / privadas PKI.
  • Mover y eliminar archivos.
  • Use bisect para encontrar el cambio que introdujo un error en particular.

Un modelo mental sólido de git y el código que se gestiona es fundamental para evitar errores.

¿Qué agregarías para una competencia / competencia avanzada?

El uso fluido es esencial para los desarrolladores y posiblemente para algunos otros miembros de su equipo. Las herramientas como Git son generales y deben aprenderse a un nivel en el que puedan ser casi automáticas. Minimizar el tiempo y la distracción producidos mediante el uso de comandos git que se repiten miles de veces al año tiene un gran valor.

Siempre habrá algunos miembros de su equipo que serán usuarios avanzados y usarán casi todos los comandos con casi todas las opciones. Mi recomendación es que se aliente a los miembros del equipo a seguir aprendiendo git (y otras herramientas) hasta que el ROI para el aprendizaje caiga por debajo del valor de hacer algo más en el proyecto, con la principal limitación de mantenerse al día con los elementos asignados de quemado del actual pique.

GIT es una herramienta justa para hacer un trabajo, y uno de sus mayores problemas es que muchos evangelistas de GIT esperan que todos los usuarios de GIT se encuentren bajo los expertos del capó entendiendo los mejores puntos de cómo funciona. Esta es la mayor debilidad de GIT: para usarla, debes saber cómo funciona. No hay recetas con GIT, se espera que seas un experto en GIT o que no lo uses. Es genial que leas Pro-GIT, tu organización necesita un "goto" GIT Guru (o dos) para maximizar la inversión en él, porque no todos los desarrolladores quieren convertirse en un GIT Guru, y eso está bien.

El equipo necesita saber cómo usar GIT (de hecho, solo necesitan saber cómo usar las partes de GIT que el flujo de trabajo requiere que usen), no cómo funciona GIT. Es perjudicial esperar que cada desarrollador conozca cada detalle sobre cada herramienta que usa. Si no tiene un libro de recetas que respalde su flujo de trabajo, no ha implementado GIT, lo ha descargado en los desarrolladores.

No le doy a los monos cómo funciona GIT, siempre y cuando sepa cómo hacer que git funcione para mí.

Si.

No importa qué herramienta haya decidido la "empresa", su equipo de desarrollo debe dedicar un tiempo a aprender cómo usar la herramienta correctamente. Nada perjudica más la productividad que un grupo de desarrolladores que temen o ignoran una herramienta. Si lo están usando mal o están trabajando en su contra, surgirán problemas y, a medida que se dirija a él, se le encargará la limpieza del desorden.

Git es una transición difícil para muchos, por lo que puede ser necesaria una sesión de entrenamiento obligatoria. Esto debería ayudar a resolver muchos de los problemas que tiene la gente.

Solo he usado Git en un entorno personal y no profesional, y aunque me gusta el poder que tiene y la idea de un control de fuente más descentralizado, tiene grandes problemas. Git tiene una abstracción permeable y se requieren múltiples comandos para hacer cosas simples (por ejemplo, para hacer un cambio: git add, git commit, luego git push). También falta parte de la documentación y / o es confusa, como con la descripción del comando rebase ... "Compromisos locales de puerto de reenvío al encabezado ascendente actualizado". No tengo idea de lo que eso significa, y aunque ahora sé que puedes mover los commits y reescribir la historia con él (otra molestia ... ¿por qué se te debería permitir hacer esto?) Nunca habría adivinado eso con ese comando descripción. Creo que es necesario leer un poco por parte de su equipo, y un poco más de capacitación proporcionada por usted.

La capacitación y la comprensión son los requisitos mínimos. Alguien a cargo debería haberse asegurado de que hubiera un plan sobre cómo lo usaría su equipo. No adoptarías un nuevo lenguaje de programación sin pautas. La capacitación del conductor es mucho más efectiva cuando se incorporan las reglas establecidas de la carretera.

No; Creo que es razonable esperar lo siguiente:

1. Realice las tareas cotidianas (commit, push, pull, branch, merge, bisect, etc.) sin tomar de la mano.
2. Realice tareas no rutinarias sin instrucciones repetidas. (Algunas repeticiones están bien, tengo que encontrarme con alguien 2-3 veces antes de que su nombre realmente se quede).

Si no pueden hacer el n. ° 1, entonces la parte de capacitación de su lanzamiento probablemente fue insuficiente. Si no pueden hacer el n. ° 2, primero asegúrese de explicar las cosas con suficiente claridad antes de enojarse demasiado.