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

El profesionalismo naturalmente exigiría 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 una pausa.

  

Tuvimos semanas de aviso previo antes del cambio.

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

  

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

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

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

Hemos estado introduciendo Git donde trabajo y naturalmente ha habido resistencia. Fue para un nuevo proyecto, por lo que ahora estamos manteniendo 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 funcione para ellos. Nos ayudó cuando nos sentamos con nuestro equipo durante un par de sesiones de una hora en las que solo mostramos casos de uso de nuestros proyectos y cómo Git lo hizo más fácil. Por ejemplo, las cosas que nos ayudaron:

• Ramas locales para fomentar la experimentación
• Git bisect para rastrear fácilmente errores
• confirmaciones 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 para 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 "experto en Git", debes sentarte y hacerlo lo más fácil posible para que la gente lo use. Quieren escribir código, no meterse 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 (tenga en cuenta que estos son desarrolladores bastante competentes):

• Git con SSH en Windows era un problema común.
• La gente tiraría, se fusionaría, pero no empujaría la combinación. Así que la gráfica sería un gran lío confuso
• El problema de rendimiento en Windows hizo que el "estado de git" tomara 15 segundos
• No se pudo averiguar cómo extraer una nueva rama. Harían un "git checkout -b" que se derivaría de lo que estuvieran trabajando
• EGit en eclipse tenía un menú abrumador. Terminé diciéndole a todos que usen la línea de comandos al principio
• Basado en el elemento anterior, fusionando y configurando git mergetool
• Confundido acerca de 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 tener algunas personas Git para orientación y estar dispuesto a ayudar. También evitaría enseñar cosas interesantes como reset / rebase / - enmendar / etc. Como la mayoría de la gente usará Git como SVN, es mejor dejar que lo descubran si así lo desean.

Competente vs. Gitmania

Un término como competencia básica puede significar cosas diferentes para diferentes personas. Mucha gente parece tener git-mania (no es que haya algo de malo en eso). Muchos de nosotros nos hemos quemado muy mal por nuestra propia falta y la de otras personas con el control de la fuente.

Por qué importa (tanto)

Las herramientas de control de fuente son críticas porque el mal uso no puede retardar a una sola 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 los sistemas que bloqueaban los archivos era particularmente problemático, y las compañías contrataban equipos de compilación discretos para que cuando alguien se metía en problemas, había un experto fluido que no hacía más que controlar la fuente y que podía curar la herida del depósito. 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, enviar y extraer actualizaciones.
  • Puede ver el estado y la actividad de revisión.
  • Puede dividirse y fusionarse rápidamente y sin introducir errores.
  • Puede usar la extracción de forma adecuada.
  • Cree comentarios de confirmación que cumplan con los criterios del grupo para comentarios.
  • Diferencias entre cambios de copia de trabajo y archivo.

• Con documentación:

  • Agregue usuarios y credenciales para el repositorio local.
  • inicia un repositorio local.
  • Administrar repositorio remoto.
  • Configure los 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 está administrando es fundamental para evitar errores.

¿Qué agregaría para la competencia / experiencia avanzada?

El uso fluido es esencial para los desarrolladores y posiblemente 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. Tener un alto valor minimiza el tiempo y la distracción que produce el uso de comandos git que se repiten miles de veces por año.

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 otra cosa en el proyecto, con la limitación principal de mantener el ritmo con los elementos de quema asignados de la corriente sprint.

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 conviertan en expertos del capo que entiendan los mejores puntos de cómo funciona. Esta es la mayor debilidad de GIT: para usarla necesitas saber cómo funciona. No hay recetas con GIT, se espera que usted sea un experto en GIT o que no lo use. Es genial que lea Pro-GIT. Su organización necesita un gurú de GIT "goto" (o dos) para maximizar la inversión en él, porque no todos los desarrolladores quieren convertirse en un gurú de GIT, y eso está bien.

El equipo debe 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 que cada desarrollador sepa cada detalle sobre cada herramienta que usa. Si no tiene un libro de recetas que admita su flujo de trabajo, no ha implementado GIT, lo ha volcado 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í.

Sí.

Independientemente de la herramienta que haya decidido la "compañía", su equipo de desarrollo debería dedicar un tiempo a aprender a usar la herramienta correctamente. Nada duele la productividad más que un montón de desarrolladores que temen o ignoran una herramienta. Si lo están utilizando mal o están trabajando en contra, los problemas surgirán y, como consecuencia de todo esto, se te pedirá que limpies el desorden.

Git es una transición difícil para muchos, por lo que una sesión de entrenamiento obligatoria puede estar en orden. 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 gran abstracción y requiere varios 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 del puerto de reenvío al cabezal ascendente actualizado". No tengo ni idea de lo que eso significa, y aunque ahora sé que puedes mover los registros y reescribirlos con la historia (otra molestia ... ¿por qué deberías permitirte hacer esto?) Nunca lo habría adivinado con ese comando. descripción. Creo que algunas lecturas por parte de su equipo, y un poco más de capacitación proporcionada por usted están en orden.

La formació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 diarias (cometer, empujar, jalar, ramificar, fusionar, bisecar, etc.) sin tener que sostenerlas.
2. Haga tareas no rutinarias sin instrucción repetida. (Unas pocas repeticiones están bien, tengo que encontrarme con alguien dos o tres veces antes de que su nombre realmente se mantenga).

Si no pueden hacer el # 1, entonces la parte de entrenamiento de su despliegue probablemente fue insuficiente. Si no pueden hacer el # 2, primero asegúrate de explicar las cosas con suficiente claridad antes de enojarte demasiado.