Control de código fuente basado en Git en la empresa: ¿Herramientas y prácticas sugeridas?

Utilizo git para proyectos personales y creo que es genial. Es rápido, flexible, potente y funciona muy bien para el desarrollo remoto.

Pero ahora es obligatorio en el trabajo y, francamente, estamos teniendo problemas.

Fuera de la caja, git no parece funcionar bien para el desarrollo centralizado en una organización grande (más de 20 desarrolladores) con desarrolladores de diferentes habilidades y niveles de sofisticación de git, especialmente en comparación con otros sistemas de control de fuente como Perforce o Subversion, que están dirigidos a ese tipo de entorno. (Sí, lo sé, Linus nunca tuvo la intención de eso).

Pero, por razones políticas, estamos atrapados con git, incluso si apesta por lo que estamos tratando de hacer con él.

Estas son algunas de las cosas que estamos viendo:

• Las herramientas de la GUI no están maduras
• Usando las herramientas de línea de comando, es demasiado fácil arruinar una fusión y borrar los cambios de otra persona.
• No ofrece permisos de repositorio por usuario más allá de los privilegios globales de solo lectura o lectura-escritura.
• Si tiene permiso para CUALQUIER parte de un repositorio, puede hacer lo mismo con CADA parte del repositorio, por lo que no puede hacer algo como crear una rama de seguimiento de grupos pequeños en el servidor central que otras personas no puedan meterse con.
• Los flujos de trabajo que no sean "todo vale" o "dictador benevolente" son difíciles de fomentar, y mucho menos de hacer cumplir
• No está claro si es mejor usar un solo gran repositorio (que permite a todos meterse con todo) o muchos repositorios por componente (lo que genera dolores de cabeza al intentar sincronizar versiones).
• Con múltiples repositorios, tampoco está claro cómo replicar todas las fuentes que alguien más tiene extrayendo del repositorio central, o hacer algo como obtener todo a las 4:30 de la tarde de ayer.

Sin embargo, escuché que la gente está usando git con éxito en grandes organizaciones de desarrollo.

Si se encuentra en esa situación, o si en general tiene herramientas, consejos y trucos para hacer más fácil y productivo el uso de git en una organización grande donde algunas personas no son fanáticas de la línea de comandos, me encantaría escuchar lo que tiene. sugerir.

Por cierto, ya hice una versión de esta pregunta en LinkedIn, y no obtuve respuestas reales, pero sí un montón de "Dios, ¡me encantaría saber eso también!"

ACTUALIZACIÓN: Déjame aclarar ...

Donde trabajo, no podemos usar NADA más que git . No es una opción. Estamos atrapados con eso. No podemos usar mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS o incluso el buen proyector de Apple que usé en 1987. Entonces, aunque puede discutir otras opciones, no obtendrá la recompensa si no habla de git.

Además, estoy buscando consejos prácticos sobre cómo usar git en la empresa . Puse una larga lista de problemas que estamos teniendo al principio de esta pregunta. Una vez más, la gente puede discutir la teoría, pero si quiere ganar la recompensa, deme soluciones.

En contra de la opinión común, creo que usar un DVCS es una opción ideal en un entorno empresarial porque permite flujos de trabajo muy flexibles. Hablaré sobre el uso de DVCS frente a CVCS primero, las mejores prácticas y luego sobre git en particular.

DVCS frente a CVCS en un contexto empresarial:

No hablaré de los pros / contras generales aquí, sino que me centraré en su contexto. Es la concepción común que el uso de un DVCS requiere un equipo más disciplinado que el uso de un sistema centralizado. Esto se debe a que un sistema centralizado le brinda una manera fácil de hacer cumplir su flujo de trabajo, el uso de un sistema descentralizado requiere más comunicación y disciplina para ceñirse a las convenciones establecidas. Si bien esto puede parecer que provoca gastos generales, veo beneficios en el aumento de la comunicación necesaria para que sea un buen proceso. Su equipo deberá comunicarse sobre el código, los cambios y el estado del proyecto en general.

Otra dimensión en el contexto de la disciplina es fomentar la ramificación y la experimentación. Aquí hay una cita de la reciente entrada de Martin Fowler en bliki sobre las herramientas de control de versiones , ha encontrado una descripción muy concisa de este fenómeno.

DVCS fomenta la ramificación rápida para la experimentación. Puede hacer ramas en Subversion, pero el hecho de que sean visibles para todos desalienta a las personas a abrir una rama para el trabajo experimental. De manera similar, un DVCS fomenta la comprobación del trabajo: la confirmación de cambios incompletos, que pueden ni siquiera compilar o aprobar pruebas, en su repositorio local. Nuevamente, podría hacer esto en una rama de desarrollador en Subversion, pero el hecho de que tales ramas estén en el espacio compartido hace que las personas sean menos propensas a hacerlo.

DVCS permite flujos de trabajo flexibles porque proporcionan seguimiento de conjuntos de cambios a través de identificadores únicos a nivel mundial en un gráfico acíclico dirigido (DAG) en lugar de simples diferencias textuales. Esto les permite realizar un seguimiento transparente del origen y el historial de un conjunto de cambios, lo que puede ser bastante importante.

Flujos de trabajo:

Larry Osterman (un desarrollador de Microsoft que trabaja en el equipo de Windows) tiene una excelente publicación de blog sobre el flujo de trabajo que emplean en el equipo de Windows. En particular, tienen:

• Un tronco limpio y de alta calidad solo con código (repositorio maestro)
• Todo el desarrollo ocurre en las ramas de funciones
• Los equipos de funciones tienen repositorios de equipo
• Ellos fusionan regularmente los últimos cambios de tronco en su rama de características ( Forward Integrate )
• Las funciones completas deben pasar varias barreras de calidad, por ejemplo, revisión, cobertura de prueba, preguntas y respuestas (repositorios por sí mismos)
• Si una función está completa y tiene una calidad aceptable, se fusiona con el tronco ( Integración inversa )

Como puede ver, teniendo cada uno de estos repositorios en vivo por sí solo, puede desacoplar diferentes equipos que avanzan a diferentes ritmos. Además, la posibilidad de implementar un sistema de puerta de calidad flexible distingue a DVCS de CVCS. También puede resolver sus problemas de permisos en este nivel. Solo un puñado de personas debe tener acceso al repositorio principal. Para cada nivel de la jerarquía, tenga un repositorio separado con las políticas de acceso correspondientes. De hecho, este enfoque puede ser muy flexible a nivel de equipo. Debe dejar que cada equipo decida si quieren compartir su repositorio de equipo entre ellos o si quieren un enfoque más jerárquico en el que solo el líder del equipo puede comprometerse con el repositorio de equipo.

(La foto fue robada de hginit.com de Joel Spolsky ).

Sin embargo, una cosa queda por decir en este punto: - aunque DVCS proporciona excelentes capacidades de fusión, nunca reemplaza el uso de la Integración Continua. Incluso en ese punto, tiene una gran flexibilidad: CI para el repositorio troncal, CI para repositorios de equipo, repositorios de preguntas y respuestas, etc.

Git en un contexto empresarial:

Git tal vez no sea la solución ideal para un contexto empresarial como ya ha señalado. Repitiendo algunas de sus preocupaciones, creo que las más notables son:

• Aún soporte algo inmaduro en Windows ( corríjame si eso cambió recientemente) Ahora Windows tiene el cliente de Windows github , tortoisegit , SourceTree de atlassian
• Falta de herramientas GUI maduras, no hay integración ciudadana de herramientas vdiff / merge de primera clase
• Interfaz inconsistente con un nivel muy bajo de abstracciones además de su funcionamiento interno
• Una curva de aprendizaje muy pronunciada para los usuarios de svn
• Git es muy poderoso y facilita la modificación del historial, muy peligroso si no sabe lo que está haciendo (y a veces lo hará incluso si pensaba que lo sabía)
• No hay opciones de soporte comercial disponibles

No quiero iniciar un git vs hg flamewar aquí, ya ha hecho el paso correcto al cambiar a un DVCS. Mercurial aborda algunos de los puntos anteriores y creo que, por lo tanto, es más adecuado en un contexto empresarial:

• Todas las plataformas que ejecutan Python son compatibles
• Excelentes herramientas de GUI en todas las plataformas principales (win / linux / OS X), integración de herramientas de fusión / vdiff de primera clase
• Interfaz muy consistente, transición fácil para usuarios de svn
• También puede hacer la mayoría de las cosas que puede hacer git, pero proporciona una abstracción más limpia. Las operaciones peligrosas son siempre explícitas. Las funciones avanzadas se proporcionan a través de extensiones que deben habilitarse explícitamente.
• El soporte comercial está disponible en selenic.

En resumen, cuando utilizo DVCS en una empresa, creo que es importante elegir una herramienta que introduzca la menor fricción. Para que la transición sea exitosa, es especialmente importante considerar las diferentes habilidades entre los desarrolladores (en lo que respecta a VCS).

Reducir la fricción:

Ok, ya que parece estar realmente atascado con la situación, quedan dos opciones en mi humilde opinión. No hay ninguna herramienta para hacer que git sea menos complicado; git es complicado. O te enfrentas a esto o trabajas alrededor de git: -

1. Obtén un curso introductorio de git para todo el equipo. Esto debe incluir solo lo básico y algunos ejercicios (¡importante!).
2. Convierta el repositorio principal a svn y deje que "young-stars" git-svn . Esto le da a la mayoría de los desarrolladores una interfaz fácil de usar y puede compensar la falta de disciplina en su equipo, mientras que las estrellas jóvenes pueden continuar usando git para sus propios repositorios.

Para ser honesto, creo que realmente tienes un problema de personas más que un problema de herramientas. ¿Qué se puede hacer para mejorar esta situación?

• Debe dejar en claro que cree que su proceso actual terminará con una base de código mantenible.
• Invierta algo de tiempo en la integración continua. Como describí anteriormente, independientemente del tipo de VCS que use, nunca hay un reemplazo para CI. Dijiste que hay personas que introducen basura en el repositorio principal: haz que arreglen su basura mientras se dispara una alerta roja y los culpa por romper la compilación (o no cumplir con una métrica de calidad o lo que sea).

Soy el ingeniero de SCM para una organización de desarrollo razonablemente grande, y nos convertimos a git desde svn durante el último año. Lo usamos de manera centralizada.

Usamos la gitosis para alojar los repositorios. Dividimos nuestros repositorios svn monolíticos en muchos repositorios de git más pequeños, ya que la unidad de ramificación de git es básicamente el repositorio. (Hay formas de evitar eso, pero son incómodas). Si desea tipos de controles de acceso por rama, gitolite podría ser un mejor enfoque. También hay una versión de GitHub dentro del firewall si le interesa gastar el dinero. Para nuestros propósitos, la gitosis está bien porque tenemos permisos bastante abiertos en nuestros repositorios. (Tenemos grupos de personas que tienen acceso de escritura a grupos de repositorios, y todos tienen acceso de lectura a todos los repositorios). Usamos gitweb como interfaz web.

En cuanto a algunas de sus preocupaciones específicas:

• fusiones: puede utilizar una herramienta de fusión visual de su elección; hay instrucciones en varios lugares sobre cómo configurarlo. El hecho de que pueda hacer la fusión y verificar su validez totalmente en su repositorio local es, en mi opinión, una gran ventaja para git; puede verificar la combinación antes de enviar nada.
• GUI: Tenemos algunas personas que usan TortoiseGit pero realmente no lo recomiendo; parece interactuar de formas extrañas con la línea de comandos. Tengo que estar de acuerdo en que esta es un área que necesita mejoras. (Dicho esto, no soy un fanático de las GUI para el control de versiones en general).
• Ramas de seguimiento de grupos pequeños: si usa algo que proporciona ACL de grano más fino como gitolite, es bastante fácil hacer esto, pero también puede crear una rama compartida conectando los repositorios locales de varios desarrolladores; un repositorio de git puede tener varios controles remotos.

Cambiamos a git porque tenemos muchos desarrolladores remotos y porque tuvimos muchos problemas con Subversion. Todavía estamos experimentando con flujos de trabajo, pero en este momento básicamente lo usamos de la misma manera que solíamos usar Subversion. Otra cosa que nos gustó fue que abrió otros posibles flujos de trabajo, como el uso de repositorios de prueba para la revisión de código y el intercambio de código entre grupos pequeños. También se anima a mucha gente a comenzar a rastrear sus scripts personales y demás porque es muy fácil crear un repositorio.

Sí, lo sé, Linus nunca tuvo la intención de eso.

En realidad, Linus sostiene que los sistemas centralizados simplemente no pueden funcionar.

Y, ¿qué pasa con el flujo de trabajo del dictador y los tenientes?

Recuerde, git es un sistema distribuido ; no intente usarlo como uno central.

(actualizado)

La mayoría de tus problemas desaparecerán si no intentas utilizar git como si fuera "svn con esteroides" (porque no lo es).

En lugar de usar un repositorio simple como servidor central donde todos pueden presionar (y potencialmente arruinarlo), configure algunos administradores de integración que manejen las fusiones, de modo que solo ellos puedan enviar al repositorio simple.

Por lo general, estas personas deben ser los líderes del equipo: cada líder integra el trabajo de su propio equipo y lo empuja al repositorio bendito.

Aún mejor, alguien más (es decir, un dictador) saca de los líderes del equipo e integra sus cambios en el repositorio bendito.

No hay nada de malo en ese flujo de trabajo, pero somos una startup con exceso de trabajo y necesitamos nuestras herramientas para sustituir el tiempo y la atención humanos; nadie tiene ancho de banda ni siquiera para hacer revisiones de código, y mucho menos para ser un dictador benevolente.

Si los integradores no tienen tiempo para revisar el código, está bien, pero aún necesita personas que integren las fusiones de todos.

Hacer git pulls no lleva tanto tiempo.

git pull A
git pull B
git pull C

Git hace sustituto para el tiempo humano y la atención; por eso fue escrito en primer lugar.

• Las herramientas de la GUI no están maduras

Las herramientas de interfaz gráfica de usuario pueden manejar las cosas básicas bastante bien.

Las operaciones avanzadas requieren una mentalidad de codificador / nerd (por ejemplo, me siento cómodo trabajando desde la línea de comandos). Se necesita un poco de tiempo para comprender los conceptos, pero no es tan difícil.

• Usando las herramientas de línea de comando, es demasiado fácil arruinar una fusión y borrar los cambios de otra persona.

Esto no será un problema a menos que tenga muchos desarrolladores incompetentes con acceso de escritura completo al "repositorio central".

Pero, si configura su flujo de trabajo para que solo unas pocas personas (integradores) escriban en el repositorio "bendito", eso no será un problema.

Git no hace que sea fácil arruinar las fusiones.

Cuando hay conflictos de fusión, git marcará claramente las líneas en conflicto para que sepa qué cambios son suyos y cuáles no.

También es fácil borrar el código de otras personas con svn o cualquier otra herramienta (no distribuida). De hecho, es mucho más fácil con estas otras herramientas porque tiende a "sentarse en los cambios" durante mucho tiempo y, en algún momento, las fusiones pueden volverse terriblemente difíciles.

Y debido a que estas herramientas no saben cómo fusionar, siempre termina teniendo que fusionar las cosas manualmente. Por ejemplo, tan pronto como alguien se comprometa con un archivo que está editando localmente, se marcará como un conflicto que debe resolverse manualmente; ahora eso es una pesadilla de mantenimiento.

Con git, la mayoría de las veces no habrá conflictos de fusión porque git realmente puede fusionarse. En el caso de que ocurra un conflicto, git marcará claramente las líneas para que sepa exactamente qué cambios son suyos y cuáles son de otras personas.

Si alguien borra los cambios de otras personas mientras resuelve un conflicto de fusión, no será por error: será porque era necesario para la resolución del conflicto o porque no saben lo que están haciendo.

• No ofrece permisos de repositorio por usuario más allá de los privilegios globales de solo lectura o lectura-escritura.

• Si tiene permiso para CUALQUIER parte de un repositorio, puede hacer lo mismo con CADA parte del repositorio, por lo que no puede hacer algo como crear una rama de seguimiento de grupos pequeños en el servidor central que otras personas no puedan meterse con.

• Los flujos de trabajo que no sean "todo vale" o "dictador benevolente" son difíciles de fomentar, y mucho menos de hacer cumplir

Estos problemas desaparecerán cuando dejes de intentar usar git como si fuera un sistema centralizado.

• No está claro si es mejor usar un solo gran repositorio (que permite a todos meterse con todo) o muchos repositorios por componente (lo que genera dolores de cabeza al intentar sincronizar versiones).

Llamada de juicio.

¿Qué tipo de proyectos tienes?

Por ejemplo: ¿la versión xy del proyecto A depende exactamente de la versión wz del proyecto B, de modo que cada vez que verifica xy del proyecto A también debe verificar wz del proyecto B, de lo contrario no se compilará? Si es así, pondría tanto el proyecto A como el proyecto B en el mismo repositorio, ya que obviamente son dos partes de un solo proyecto.

La mejor práctica aquí es usar tu cerebro

• Con múltiples repositorios, tampoco está claro cómo replicar todas las fuentes que alguien más tiene extrayendo del repositorio central, o hacer algo como obtener todo a las 4:30 de la tarde de ayer.

No estoy seguro de lo que quieres decir.

Recomiendo encarecidamente http://code.google.com/p/gerrit/ para trabajos empresariales. Le brinda control de acceso además de un flujo de trabajo integrado basado en revisiones. Se autentica contra cualquier sistema LDAP. Puede conectarlo a Hudson con http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , lo que le permite crear y probar los cambios mientras aún se están revisando; es una configuración realmente impresionante.

Si decides usar gerrit, te recomiendo que intentes mantener un historial bastante lineal, no un historial ramificado como les gusta a algunos de los tipos de código abierto. Gerrit expresa esto como "permitir solo cambios rápidos". Luego, puede usar la ramificación y la fusión de la forma en que está acostumbrado, para lanzamientos y otras cosas.

Respondo a esta pregunta basándome en mi experiencia como gerente de desarrolladores en una gran empresa de telecomunicaciones, donde adoptamos Git en 2010.

Aquí tienes un conjunto de problemas bastante diferente:

• flujos de trabajo
• herramientas del cliente
• integración y control de acceso al servidor

Flujos de trabajo

Adoptamos con éxito un modo de repositorio central: lo que tenemos en nuestro proyecto empresarial (un gran portal para una base de 5 millones de usuarios) es un repositorio central de facto que produce las compilaciones oficiales y luego se llevan a través del proceso de entrega (que, en nuestra caso, se compone de tres niveles de prueba y dos implementaciones). Cada desarrollador administra su propio repositorio y nosotros trabajamos rama por función.

Herramientas de cliente

Ahora hay varias opciones disponibles, esta es ahora un área muy concurrida. Muchos desarrolladores están utilizando con éxito IntelliJ Idea y Eclipse con el complemento Git , sin ninguna otra cosa. Además, la mayoría de los desarrolladores de Linux están utilizando el cliente CLI git, sin ningún problema. Algunos desarrolladores de Mac están utilizando Tower Git con éxito . Tenga en cuenta que ninguno de estos clientes puede evitar que el usuario "se equivoque" con el repositorio central: se necesita un mecamismo de control del lado del servidor

Integración y control de acceso al servidor

Si desea evitar que los desarrolladores "estropeen" su repositorio de Git, debe elegir una solución que:

• expone una interfaz de administración web decente para realizar todas las operaciones
• le permite hacer cumplir las identidades de los usuarios (usar un repositorio de Git "simple" es extremadamente fácil de confirmar en nombre de otra persona)
• le proporciona seguridad detallada (para que, por ejemplo, pueda evitar FORCE-PUSH y configurar algunas ramas para que sean de solo lectura para algunos desarrolladores / grupos)
• integre con su sistema de autenticación corporativo (es decir, LDAP, Windows ActiveDirectory)
• le proporciona una auditoría completa (el cumplimiento de SOX es a veces muy importante para las grandes corporaciones)

No hay tantas soluciones del lado del servidor listas para usar que puedan ayudar con esto, le sugiero que consulte una de estas:

• Gitorious : puede proporcionar seguridad de nivel de acceso básico, pero carece de control de permisos de grano fino listo para usar, por lo que probablemente tendrá que codificar para manejar escenarios como los permisos de nivel de rama. También carece de integración con los mecanismos de autenticación corporativos existentes.
• GitHub Enterprise: publicado recientemente por GitHub, presenta GitHub en su empresa. Carece de conformidad con SOX y seguridad de grano fino
• Gerrit : puede proporcionar seguridad de nivel de acceso de gran calidad e integración con sistemas de autenticación corporativos, pero carece de cumplimiento SOX y SSO. Además, algunas operaciones solo se pueden realizar a través de SSH a través de CLI
• GitEnterprise : proporciona permisos a nivel de sucursal, SSO, cumplimiento de SOX, administración completa basada en web. Recientemente también se integró con Gerrit, por lo que también le proporciona una instancia completa de Gerrit

¡Espero que esto ayude!

Parece que su problema es que no ha decidido ni instituido un flujo de trabajo. Git es lo suficientemente flexible como para usarlo como svn o cualquier otro VCS, pero es tan poderoso que si no establece reglas que todos deben seguir, terminará con un desastre. Recomendaría el flujo de trabajo dictador-teniente que alguien mencionó anteriormente, pero combinado con el modelo de ramificación descrito por Vincent Driessen . Para obtener más información, consulte estos screencasts de David Bock y este de Mark Derricutt .

En las herramientas , los usuarios de MacOS-X encuentran GitX (http://gitx.frim.nl/) muy simple y efectivo. El inconveniente es que no admite los ganchos de Git Client (los que están debajo de $ GIT_ROOT / .git / hooks).

En general, hago mucho por elegir una herramienta que admita el control de acceso detallado en: - ramas (para segregar las ramas de versión estable con seguridad estricta de las ramas temáticas que necesitan más agilidad y flexibilidad) - aplicación de la identidad (autor / autor ). Esta es CLAVE para SOX - restricciones de comandos de git - pista de auditoría. Esto es CLAVE para SOX

Los que he usado con éxito con esas funciones son:

1. Revisión del código Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), usa Gerrit 2.1.8 detrás de escena

PD : No subestime el cumplimiento de SOX y CMMI : muchas veces existe un conjunto limitado de opciones que está dictado por las políticas empresariales de seguridad de su empresa.

Espero que esto ayude.

Luca.

Recientemente cambiamos de svn a git. Debido a que git-daemon no funciona con msysgit, optamos por un enfoque de repositorio central en un servidor Linux con gitosis.

Para eliminar la posibilidad de estropear el maestro, simplemente lo eliminamos. En su lugar, preparamos todas las versiones fusionando las ramas que se seleccionan para probar y etiquetando la fusión. Si pasa las pruebas, la confirmación se etiqueta con una versión y se pone en producción.

Para manejar esto, tenemos un rol rotativo de administrador de versiones. El administrador de versiones es responsable de revisar cada rama antes de que esté lista para la prueba. Luego, cuando el propietario del producto decide que es hora de agrupar las ramas aprobadas para una nueva versión de prueba, el administrador de versiones realiza la fusión.

También tenemos un rol rotativo de mesa de ayuda de nivel 2 y al menos para nosotros la carga de trabajo es tal que es posible tener ambos roles al mismo tiempo.

Como beneficio de no tener un maestro, no es posible agregar ningún código al proyecto sin pasar por el administrador de versiones, por lo que descubrimos directamente cuánto código se agregó silenciosamente al proyecto antes.

El proceso de revisión comienza cuando el propietario de la sucursal envía la diferencia al panel de revisión y coloca un post-it verde en la pizarra con el nombre de la sucursal (tenemos un flujo de trabajo basado en Kanban) en "para revisión", o si es parte de un usuario completo. historia, mueva la tarjeta de historia completa a "para revisión" y coloque la publicación en ella. El administrador de relase es el que mueve las tarjetas y los post-its a "listo para la prueba" y luego el propietario del producto puede seleccionar cuáles incluir en la próxima versión de prueba.

Al realizar la fusión, el administrador de versiones también se asegura de que la confirmación de fusión tenga un mensaje de confirmación sensible que pueda usarse en el registro de cambios para el propietario del producto.

Cuando una versión se ha puesto en producción, la etiqueta se utiliza como la nueva base para las sucursales y todas las sucursales existentes se fusionan con ella. De esta forma, todas las ramas tienen un padre común que facilita el manejo de fusiones.

También agregaré una publicación de "¿lo has considerado?".

Una de las mejores cosas de Bazaar es su flexibilidad. Aquí es donde supera a todos los demás sistemas distribuidos. Puede operar Bazaar en modo centralizado, modo distribuido u obtener esto: ambos (lo que significa que los desarrolladores pueden elegir con qué modelo se sienten cómodos o cuál funciona mejor para su grupo de trabajo). También puede desconectar un repositorio centralizado mientras está de viaje y volver a conectarlo cuando regrese.

Además de eso, excelente documentación y algo que hará feliz a su empresa: soporte comercial disponible.

• Instale una interfaz web decente, como Github FI
• Cíñete a un modelo relativamente centralizado (inicialmente) para que la gente se sienta cómoda.
• Ejecute una compilación de integración continua para cada rama compartida.
• Comparta un buen conjunto de opciones de configuración global de git.
• Integre git en su shell, con la finalización de bash y un mensaje con la rama actual.
• Pruebe la integración de Git de IntelliJ como una herramienta de combinación.
• Asegúrese de hacer .gitignore según corresponda.

Con respecto a los puntos 3 y 4 (permisos por usuario, por sección, por rama), eche un vistazo a gitolite (cubierto en el libro Pro Git: http://progit.org/book/ch4-8.html ).

Política o no, Git es una opción tan buena como cualquier otra DCVS. Como cualquier herramienta poderosa, vale la pena dedicar un poco de tiempo a comprender cómo está diseñada para funcionar la herramienta y, con este fin, recomiendo encarecidamente el libro Pro Git. Pasar un par de horas con él le ahorrará mucha frustración a largo plazo.

GUI: Por el momento, TortoiseGit v1.7.6 debería funcionar bien para la mayoría de las operaciones diarias. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc ... También admite x64 de forma nativa

Para usar git de manera eficiente en un equipo de desarrollo con muchos desarrolladores, se requiere un sistema de CI que construya y pruebe continuamente. Jenkins proporciona un vehículo de este tipo y lo recomiendo mucho. La pieza de integración debe hacerse pase lo que pase y es mucho más económico hacerlo antes y con más frecuencia.

Más adecuado para el desarrollo colaborativo que la gitosis o la gitolita, pero el código abierto es Gitorious . Es una aplicación Ruby on Rails que maneja la administración de repositorios y la fusión. Debería resolver muchos de tus problemas.

Git permite crear sucursales privadas. Esto anima a los desarrolladores a comprometerse con frecuencia para dividir las modificaciones en pequeñas confirmaciones. Cuando el desarrollador está listo para publicar sus cambios, empuja al servidor central. Puede hacer uso de scripts de confirmación previa para verificar su código si es necesario.

NXP administra Git y Subversion con una plataforma común (a escala empresarial), integrando el desarrollo móvil de Android con proyectos de software tradicionales: http://www.youtube.com/watch?v=QX5wn0igv7Q