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

48

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?

Joshua Smith
fuente
30
¿La compañía ofreció algún entrenamiento en Git?
Yannis
99
Cualquier desarrollador que no sea productivo es una responsabilidad. Asumiendo que son productivos en general, saber o no saber git es intrascendente. Al final del día, es solo otra herramienta.
MrFox
99
Yo llamaría la comprensión de cómo funcionan las ramas Git parte de "competencia básica" con ella ...
Shauna
16
Si tus compañeros de equipo no pueden entender a Git, tienes mayores problemas que el control de la fuente.
Jordan Bentley
44
@Caleb Eso no fue una jactancia. Lejos de ahi.
Joshua Smith

Respuestas:

49

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).

Miguel
fuente
3
Concedido. Hicieron el cambio a un sistema que casi nadie entendió. Hubiera sido conveniente ofrecer capacitación antes del cambio. Sin embargo, me sentí cómodo usando Git con menos de una semana de práctica. No siento que estoy sobrepasando, así que me pregunto si es apropiado esperar que los demás también estén practicando.
Joshua Smith el
3
¿Alguien se molestó en descubrir los flujos de trabajo que tenía y asignarlos a las primitivas que el nuevo VCS tiene para ofrecer? Es bastante fácil dispararte en el pie con comandos que suenan como los que estás acostumbrado, y realmente necesitas a alguien para orquestar algo como esto. ¿Dónde está el tipo responsable de este cambio?
Lars Viklund
19
@JoshuaSmith Al cambiar los estándares o las herramientas de desarrollo, siempre debe operar en una transición de estilo "No Child Left Behind". El equipo solo puede moverse tan rápido como su miembro más lento, así que asegúrese de que las cosas se aclaren y se reduzcan al nivel más bajo posible antes de que ocurra la transición. Claro que puede etiquetar la responsabilidad de tantas personas como desee, pero deshacerse de las "responsabilidades" es una tarea difícil y complicada, especialmente sobre algo tan trivial como una herramienta de control de fuente.
maple_shaft
3
Suena como que "les arrojaste GIT" en lugar de "Lanzaste un nuevo sistema de control de revisiones": GIT es un programa que controla las fuentes. No es un sistema de control de código fuente -que requeriría manuales de usuario, de formación, programas de mantenimiento, gestión del ciclo de vida, etc. Por favor, dime que tienes una copia de seguridad en su lugar
mattnz
77
Aprender cómo funciona git es bastante trivial. Definitivamente no lleva un mes aprender a usarlo. En mi opinión, un simple "Chicos, vamos a usar git en unas pocas semanas. Tómese unas horas para aprender cómo usarlo, hay muchos recursos en línea", hubiera sido más que suficiente.
Moox
34

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.

Críptico
fuente
77
@JoshuaSmith Parece que tienes grandes expectativas de la gente. ¿Te sientes decepcionado con tus compañeros a menudo?
maple_shaft
44
@maple_shaft Raramente estoy decepcionado con mis compañeros en este equipo (mi último trabajo fue una historia diferente). Por lo general, la gente aquí es profesional y es un placer trabajar con ellos. Y sí, tengo grandes expectativas para mí y para quienes me rodean. Sin embargo, no soy un idiota al respecto. Esto es probablemente ingenuo, pero siento que si todos exigimos excelencia unos a otros, inevitablemente mejoraremos.
Joshua Smith el
99
@ JoshuaSmith, si esperas que la gente tenga tiempo regularmente para leer libros, voy a arriesgarme a adivinar: no tienes hijos, ¿verdad?
Kyralessa
13
@JoshuaSmith, ¿a la gente se le paga por leer esos libros? Si mi jefe me dijera "estamos cambiando de tecnología, espero que la hayas aprendido en tu tiempo libre para el próximo mes", estaría muy enojado.
Matsemann el
13
@ JoshuaSmith, sí, lo diría, todo lo que un empleado hace en su propio tiempo es adicional, no obligatorio. Por lo tanto, compre el cambio, debe proporcionarles suficiente información para usar la herramienta, o suficiente tiempo durante el trabajo para que lo aprendan ellos mismos (por lo general, esto se proporciona en forma de capacitación, incluso si es solo una sesión de capacitación a la hora del almuerzo). Ahora, si los empleados eran autónomos, hay un caso para ellos que se han entrenado, pero no durante su contrato. Los empleados esperan ciertos beneficios, como la capacitación, y no sentirse estresados ​​por tener un cambio de trabajo como este.
gbjbaanb
13

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.

DesarrolladorDon
fuente
11

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í.

Mattnz
fuente
1
Y ahí radica la necesidad de un entrenamiento personalizado ... y, de nuevo, ni Linus espera que nadie adopte todos los tecnicismos de git, es por eso que hay dos clases de comandos: porcelana y fontanería.
ZJR
1
Hay muchas recetas para git si todo lo que quiere hacer es migrar de un flujo de trabajo que usó en Brand X a un flujo de trabajo en Git.
Jherico
10

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.

Bill Leeper
fuente
3
"Nada perjudica más la productividad que un grupo de desarrolladores que temen o ignoran una herramienta". Por lo tanto, presumiblemente una compañía estaría loca por vivir con una herramienta en la que el equipo no ha sido entrenado y no entiende.
Jaydee
Las empresas, especialmente las grandes, a veces tienen que impulsar la tecnología. También puede ser un equipo dentro de una organización que ya ha realizado el impulso inicial y está utilizando la herramienta por completo.
Bill Leeper
3

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.

Fred Thomsen
fuente
2

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.

JeffO
fuente
1

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.

pgs
fuente
Esto no es realmente una respuesta a la pregunta; la pregunta era qué nivel de competencia debería esperar de los demás, no cómo mejoraría su competencia. Quitaré el voto negativo cuando me notifique en un comentario con @MyName que ha corregido su respuesta para estar en el tema.
Jimmy Hoffa
@ Jimmy Jimmy Creo que entiendes mal mi respuesta. Deben ser competentes en sus tareas cotidianas / rutinarias, y realizar otras tareas razonablemente rápido. Identifiqué un par de posibles causas , pero traté de evitar la prescripción de medidas correctivas. Estás leyendo entre líneas y extrapolando si eso es lo que ves.
pgs
No, la pregunta es "¿Debería esperar que mi equipo tenga más que una competencia básica ..." y usted no dijo "Sí, aquí está el por qué" ni dijo "No, aquí está el por qué". Respondiste una pregunta con una pregunta. Aprecio que su respuesta sea bien pensada y el contenido sea útil, pero aún así debe responder la pregunta con un sí o un no y tratar de respaldar por qué piensa que sí o no ... Luego, siéntase libre de dejar debajo de su respuesta el contenido actual . ¿Tener sentido?
Jimmy Hoffa
@JimmyHoffa Mi respuesta es "No, aquí hay un mínimo que debes esperar razonablemente"; Simplemente no lo dije en esas palabras exactas.
pgs
Oh, pensé que estabas aludiendo a un "sí", pon ese prefacio y está abordando la pregunta, de lo contrario, simplemente no tiene sentido je
Jimmy Hoffa