¿Cuál es el flujo de trabajo con 2 personas en un proyecto?


18

Vengo a ti como un programador novato que ha estado trabajando en su propio proyecto (que está progresando muy bien). Mi cofundador también ha estado aprendiendo a programar y ha llegado a un punto en el que probablemente podría comenzar a arreglar algunas cosas y hacer que algunas cosas sucedan.

Hizo una muy buena pregunta, que era "cómo funcionará esto". Algo sobre lo que solo podría teorizar, ya que nunca lo he programado con otra persona. ¿Podría aconsejarme sobre el mejor flujo de trabajo? Usamos git.

¿Deberíamos poseer partes específicas del sistema? ¿Ingresando código? ¿Revisión de código?

¿Cómo trabajas con> 1 dev?


1
Mi mejor pista es echar un vistazo a esto: nvie.com/posts/a-successful-git-branching-model Es una (buena) forma de organizar el código en equipo, y también lo usamos

¿Escribes pruebas?
NARKOZ

... @ NARKOZ - todavía no. Saltamos un poco. Es algo que me gustaría hacer, acabo de comprar un libro.

2
@Geoff Wright: ingrese a su perfil y acepte (presione el botón de marca de verificación al lado) algunas de las respuestas que la gente ha proporcionado tan amablemente a sus preguntas: stackoverflow.com/users/661241/geoff-wright
iwasrobbed

1
Use bitbucket.com para repositorios privados
Klevis Miho

Respuestas:


23

Trabajo en un equipo que usa git, donde más de 40 desarrolladores están trabajando en múltiples repositorios de código (más de 100) en cualquier momento. También comenzamos con muy pocos desarrolladores, aumentando el tamaño del equipo en unos pocos años. Al principio, sin embargo, con pocas personas puedes escapar sabiendo solo un mínimo de git. Con el tiempo mejorarás tu git fu, descubriendo potentes funciones.

  1. Necesitarás un lugar para alojar tu código. Considera usar github o gitorious . Ambos son de uso gratuito, pero sus repositorios serán públicos y visibles para otros. Si desea repositorios privados , puede alojarlos en github de forma gratuita o instalar y alojar su propio servidor .
  2. Al principio, es mejor no preocuparse por los flujos de trabajo avanzados que implican bifurcación, solicitudes de extracción. Puede comenzar usando git de manera centralizada (¡estremecimiento!). Trate su copia alojada como la copia autorizada de su código fuente. Llamemos a este repositorio upstream.
  3. Uno de ustedes confirma todo el código en un repositorio local de git y lo envía a este upstreamrepositorio.
  4. El otro miembro del equipo puede clonar este repositorio.
  5. Un conjunto de comandos mínimos que necesita para aprender son clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Aprende más sobre ellos en gittutorial .
  6. Cualquiera de ustedes ahora puede trabajar en cualquier parte del código. No se preocupe por lo que sucede cuando ambos editan el mismo archivo. Git es realmente bueno manejando fusiones y arreglando conflictos.
  7. Haga pequeñas confirmaciones atómicas y escriba buenos mensajes de registro . Use el tiempo presente para los registros de confirmación. Puede realizar cualquier cantidad de confirmaciones que desee en su copia local, ya que no afecta el trabajo de la otra persona.
  8. Cuando crea que su código está listo para ser compartido con otros, publíquelo en el upstreamrepositorio. Una buena práctica es tirar siempre antes de empujar . De esta manera, mantienes tu repositorio sincronizado con otros cambios.
  9. Repita los pasos 7y 8.

Una vez que se sienta cómodo con este flujo de trabajo, puede avanzar hacia cosas más avanzadas como: ramas tópicas, bifurcación, solicitudes de extracción, fusión, confirmaciones interactivas, etc.

Si realmente quieres revisiones de código, es factible solo con git y correo electrónico. Cuando el tamaño de su equipo supera los 10+, lo ideal es hacerlo mejor con algún tipo de herramienta en línea. En la práctica, hay muchas formas de hacerlo, y esta es solo una forma simple:

  1. Cree un conjunto de confirmaciones para revisar git format-patch. Esto generará un conjunto de archivos de parche. Envíe estos parches por correo electrónico al revisor.
  2. El revisor puede aplicar los parches con git apply. Esto aplica el parche pero no crea una confirmación.
  3. Revise el código y envíe un correo electrónico con sugerencias.
  4. Repita 1-2-3 hasta que sea satisfactorio.
  5. El revisor confirma que los parches pueden ser empujados upstream.

También me gustaría agregar git rebase a esta lista.
alock27

1
No estoy de acuerdo con que stash, apply, format-patchson parte del conocimiento mínimo. Normalmente espero unos meses antes de enseñar esas cosas. Supongo que> 50% de los desarrolladores no se esconden.
Michael Durrant

1
Llame upstream originy ayudará a que otros ejemplos (que normalmente se usan origin) sean más fáciles de seguir.
Michael Durrant

2

Yo uso github y toda su funcionalidad para esto. échale un vistazo en http://www.github.com/ Para que puedas usar sucursales, tenedores, problemas, solicitudes de extracción para trabajar con tu socio.


0

Lo primero que haría es buscar en un repositorio central de código para que los cambios puedan fusionarse y mantenerse sincronizados entre sus dos proyectos. SVN es una buena y fácil que he usado en el pasado y ha existido el tiempo suficiente para que sea SVN bastante maduro .

Después de eso, identificaría entre ustedes dos los roles que cualquiera de ustedes va a desempeñar, es decir

  1. ¿Va a escribir la funcionalidad del código en forma aleatoria o una persona va a hacer correcciones de errores mientras la otra continúa con las características?
  2. ¿Desea crear un conjunto de estándares de codificación básicos, es decir, posición de llaves, nombre de variable de miembro privado, convención de nombres de variables y métodos (CamelCase, etc.)
  3. ¿Con qué frecuencia necesita registrarse? Sugeriría al menos una vez al día para asegurarse de que ambos estén viendo lo que el otro está haciendo, especialmente desde el principio. Aunque siempre asegúrese antes de registrarse, el código se puede construir.
  4. Él es el jefe, pero ¿vas a ser el líder de programación?

¡Buena suerte!


1
SVN es una opción decente (y actualmente la estoy usando en el trabajo) ... pero Git y Hg me han parecido un poco mejores ya que puedo comprometerme localmente (y revertir cuando hice algo tonto) sin obligar a otros a tratar (si se actualizan) con mi código que puede no funcionar. Honestamente, comencé a usar Git en la oficina por este motivo, pero aún puedo publicar mis cambios en SVN usando git-svn
Ken Henderson
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.