Flujo de trabajo de Git con múltiples desarrolladores, manteniendo un historial limpio

Question

Sandofsky advocates siendo muy estricto con el historial de su "principal" repositorio, manteniéndolo limpio sin saturarlo con las ramificaciones y confirmaciones del punto de control.

Nunca debe fusionar una sucursal privada directamente en una sucursal pública con una combinación de vanilla. Primero, limpia tu sucursal con herramientas como restablecer, rebase, squash merge, y cometer modificaciones.

Trata la historia pública como inmutable, atómica y fácil de seguir. Trate la historia privada como desechable y maleable.

Esto atrae a mí, y yo estaba pensando en la implementación de un flujo de trabajo donde mis colegas tienen cada uno su propio repositorio remoto para empujar a, y hacer unas peticiones de tracción cuando se haya finalizado el trabajo en una rama y limpiado el cometer el historial. Posteriormente, I (el 'gerente de integración') fusiona esos commits limpios en la rama de desarrollo general.

Supongo que este enfoque significa que el repositorio bendecido no tendrá ramas distintas de the master and develop branch. Las ramas de funciones solo existirán en su repositorio local; si se necesita colaboración en una sucursal, esto puede suceder mediante el envío de la sucursal al depósito remoto de uno de los empleados colaboradores.

Sin embargo, el Pro Git book describe esto como un flujo de trabajo para "public small projects". ¿Esto significa que es mejor utilizar un flujo de trabajo diferente en nuestro caso, como empujar las ramas terminadas al repositorio bendecido en lugar de a un repositorio personal?

Para ser claros: no estoy dispuesto a agregar complejidad innecesaria o sobrecarga. Mi objetivo es establecer un flujo de trabajo en el que mis colegas y yo podamos trabajar de forma asíncrona, puedo revisar su trabajo cuando haya terminado y devolverlo con comentarios o combinarlo en la base de código si todo está bien.

---

Editar: Aparentemente la pregunta que no estaba claro, por lo que voy a tratar de resumir:

Habría una desventaja en tener mis colegas empujan a sus ramas directamente a nuestro repositorio bendita (por ejemplo, ¿"contaminaría" su historia de alguna manera)?

Answer 1

Un par de disadvatages:

La cesión temporal bendito con bastante rapidez (dependiendo del número de desarrolladores y características) estar atestado de muchas ramas. Está más limpio si solo contiene, p. master y develop, que master, develop, featureA, featureB, featureC .. etc. Sin embargo, siempre puedes limpiar el repositorio borrándolos en el control remoto (origen de git push: featureA) pero agrega trabajo de limpieza extra.

Además, cuando las personas obtienen del repositorio bendecido sus repositorios contendrán referencias remotas a todas esas ramas y cuando elimine las sucursales remotas, tendrán que "seleccionar el origen de la pasa remota" para limpiar las referencias que están ya no es válido, lo que también agrega trabajo adicional.

Answer 2

No veo ninguna razón por la cual este flujo de trabajo no funcione para usted: el énfasis en público puede deberse a que para un proyecto público, es mucho más importante mantener una historia limpia e inmutable.

Answer 3

Creo Gitolite"personal" branches puede satisfacer sus necesidades muy bien. Es como tener un área personal (a.k.a.espacio de nombre) donde cada desarrollador puede (incluso forzosamente) presionar. Por el contrario, master es de solo lectura para todos los desarrolladores, pero es un integrador.

Si Alicia de .git/config contiene la siguiente configuración:

[remote "origin"] 
     url = git@server:project 
     push = +refs/heads/*:refs/heads/personal/alice/* 
     fetch = +refs/heads/master:refs/remotes/origin/master 
     fetch = refs/heads/personal/alice/*:refs/remotes/origin/me/* 
     fetch = +refs/heads/personal/bob/*:refs/remotes/origin/bob/* 

entonces Alice vería

• sus ramas en el servidor como origin/me/branch y
• ramas de Bob como origin/bob/branch.

De esta manera, Alice puede:

• trabajo en sus ramas y tire/empujarlos al servidor
• comenzar una nueva rama fuera de master
• iniciar una nueva rama fuera de Bob ramas
• hacer una copia de seguridad de su trabajo simplemente presionando en el servidor.

Gitolite se puede configurar de tal manera que Alice no puede escribir en el espacio personal de Bob y viceversa:

@users = alice bob 
@integrators = john 
@repos = repo1 repo2 

repo @repos 
    RW+       = @integrators 
    RW+  personal/USER/  = @users