log - git remove tag

Control de fuente basado en Git en la empresa: ¿herramientas y prácticas sugeridas? (16)

Uso 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 gran organización (más de 20 desarrolladores) con desarrolladores de distintas capacidades y niveles de sofisticación 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 lo pensó así).

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

Estas son algunas de las cosas que estamos viendo:

Las herramientas GUI no están maduras
Usando las herramientas de línea de comando, es muy 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 de 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.
Flujos de trabajo distintos de "todo vale" o "dictador benevolente" son difíciles de alentar, y mucho menos hacer cumplir
No está claro si es mejor usar un único repositorio grande (que permite a todo el mundo meterse con todo) o muchos repositorios por componentes (lo que hace que los dolores de cabeza intenten sincronizar las versiones).
Con varios repositorios, tampoco está claro cómo replicar todas las fuentes que tiene otra persona extrayendo del repositorio central, o hacer algo como obtener todo a partir de las 4:30 de la tarde de ayer.

Sin embargo, he escuchado que las personas están usando git con éxito en grandes organizaciones de desarrollo.

Si estás en esa situación, o si en general tienes herramientas, consejos y trucos para hacer que sea más fácil y productivo usar git en una gran organización donde algunos no son fanáticos de la línea de comandos, me encantaría saber lo que tienes. sugerir.

Por cierto, ya he preguntado una versión de esta pregunta en LinkedIn, y no obtuve respuestas reales, pero sí "¡Dios mío, también me gustaría saberlo!"

ACTUALIZAR: 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, bazar, Darcs, monotono, Perforce, Fossil, AccuRev, CVS o incluso el buen proyector de Apple que utilicé en 1987. Entonces, si puedes discutir otras opciones, no obtendrás la recompensa si no hablas de git.

Además, estoy buscando consejos prácticos sobre cómo usar git en la empresa . Puse toda una lista de problemas que tenemos en la parte superior de esta pregunta. Una vez más, la gente puede debatir sobre la teoría, pero si quieres ganar la recompensa, dame soluciones.

Sí, lo sé, Linus nunca lo pensó así.

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

Y, ¿qué pasa con el flujo de trabajo de dictadores y tenientes?

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

(actualizado)

La mayoría de tus problemas desaparecerán si no tratas de usar 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 equivocarse), configure unos pocos gerentes de integración que manejen fusiones, de modo que solo ellos puedan acceder 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) extrae 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 humana; nadie tiene ancho de banda para siquiera hacer revisiones de código, y mucho menos 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 toma tanto tiempo.

git pull A git pull B git pull C

git sustituye el tiempo y la atención humanos; por eso fue escrito en primer lugar.

Las herramientas GUI no están maduras

Las herramientas GUI 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). Toma un poco de tiempo comprender los conceptos, pero no es tan difícil.

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

Esto no será un problema a menos que tengas muchos desarrolladores incompetentes con acceso completo de escritura 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 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 más fácil con estas otras herramientas porque tiendes a "sentarte en los cambios" durante mucho tiempo y en algún punto las fusiones pueden ser terriblemente difíciles.

Y debido a que estas herramientas no saben cómo fusionarse, terminas teniendo que fusionar cosas manualmente. Por ejemplo, tan pronto como alguien realiza una confirmación de 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 puede fusionarse. En el caso en que se produzca un conflicto, git marcará claramente las líneas para que sepa exactamente cuáles son los cambios que 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 fue necesario para la resolución del conflicto, o porque no sabe lo que está haciendo.

No ofrece permisos de repositorio por usuario más allá de los privilegios globales de solo lectura o de 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.
Flujos de trabajo distintos de "todo vale" o "dictador benevolente" son difíciles de alentar, y mucho menos hacer cumplir

Estos problemas desaparecerán cuando deje de intentar usar git como si se tratara de un sistema centralizado.

No está claro si es mejor usar un único repositorio grande (que permite a todo el mundo meterse con todo) o muchos repositorios por componentes (lo que hace que los dolores de cabeza intenten sincronizar las 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 compruebe xy del proyecto A también tenga que ejecutar wz del proyecto B, de lo contrario no se compilará? De ser así, pondría el proyecto A y 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 varios repositorios, tampoco está claro cómo replicar todas las fuentes que tiene otra persona extrayendo del repositorio central, o hacer algo como obtener todo a partir de las 4:30 de la tarde de ayer.

No estoy seguro de lo que quieres decir.

Añadiré una publicación de "has considerado" también.

Una de las mejores cosas de Bazar es su flexibilidad. Aquí es donde supera a todos los otros sistemas distribuidos. Puede operar Bazar en modo centralizado, modo distribuido, u obtener esto: ambos (es decir, 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.

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

DVCS vs. CVCS en un contexto empresarial:

No hablaré sobre los pros / contras generales aquí, sino que me enfocaré en tu contexto. Es la concepción común, que usar un DVCS requiere un equipo más disciplinado que usar un sistema centralizado. Esto se debe a que un sistema centralizado le proporciona una forma fácil de aplicar su flujo de trabajo, usar un sistema descentralizado requiere más comunicación y disciplina para cumplir con las convenciones establecidas. Si bien esto puede parecer que induce una sobrecarga, veo beneficios en la mayor comunicación necesaria para que sea un buen proceso. Su equipo deberá comunicar el código, los cambios y el estado del proyecto en general.

Otra dimensión en el contexto de la disciplina es fomentar ramificaciones y experimentos. Aquí hay una cita de la reciente entrada bliki de Martin Fowler en Version Control Tools , que ha encontrado una descripción muy concisa para 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 desanima a las personas a abrir una sucursal para trabajos experimentales. De manera similar, un DVCS fomenta el chequeo del trabajo: la realización de cambios incompletos, que incluso pueden no compilar o pasar las pruebas, a su repositorio local. De nuevo, podría hacer esto en una sucursal de desarrolladores en Subversion, pero el hecho de que dichas sucursales estén en el espacio compartido hace que las personas tengan menos posibilidades de hacerlo.

DVCS permite flujos de trabajo flexibles porque proporcionan seguimiento de conjuntos de cambios a través de identificadores únicos globales 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 en el blog sobre el flujo de trabajo que emplean en el equipo de Windows. Lo más notable es que tienen:

Un tronco limpio y de alta calidad con solo código (repositorio principal)
Todo el desarrollo ocurre en las ramas de características
Los equipos de características tienen repos de equipo
Con frecuencia fusionan los últimos cambios de troncales en su rama de características ( Forward Integrate )
Las características completas deben pasar por varias puertas de calidad, por ejemplo, revisión, cobertura de prueba, preguntas y respuestas (repos por su cuenta)
Si una característica se completa y tiene una calidad aceptable, se fusiona en el tronco ( Invertir integración )

Como puede ver, tener cada uno de estos repositorios en vivo por su cuenta 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 un CVCS. Puede resolver sus problemas de permisos en este nivel también. Solo un puñado de personas debería tener acceso al repositorio maestro. Para cada nivel de la jerarquía, tenga un repo separado con las políticas de acceso correspondientes. De hecho, este enfoque puede ser muy flexible a nivel de equipo. Debes dejar que cada equipo decida si quiere compartir el repositorio de su equipo entre ellos o si quieren un enfoque más jerárquico donde solo el líder del equipo puede comprometerse con el repositorio del equipo.

(La imagen es robada del hginit.com de Joel Spolsky).

Sin embargo, una cosa queda por decir en este punto: aunque DVCS proporciona grandes capacidades de fusión, nunca es un reemplazo para usar la integración continua. Incluso en ese momento tiene una gran flexibilidad: CI para el repositorio troncal, CI para repos de equipo, repositorios Q & A, etc.

Git en un contexto empresarial:

Es posible que Git no sea la solución ideal para un contexto empresarial como ya lo ha señalado. Repitiendo algunas de sus preocupaciones, creo que son especialmente las siguientes:

~~Todavía soporte algo inmaduro en Windows (~~ corrígeme ~~si eso cambió recientemente)~~ Ahora Windows tiene el cliente de windows github , tortoisegit , SourceTree from atlassian
Falta de herramientas de GUI maduras, no integración de vdiff / merge de primera clase para ciudadanos
Interfaz inconsistente con un nivel muy bajo de abstracciones en la parte superior de su funcionamiento interno
Una curva de aprendizaje muy empinada para usuarios de svn
Git es muy poderoso y hace que sea fácil modificar la historia, muy peligroso si no sabes lo que estás haciendo (y a veces incluso si creías que lo sabías)
No hay opciones de soporte comercial disponibles

No quiero comenzar aquí una llamarada de git contra hg, ya has 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 primera clase de fusión / herramienta vdiff
Interfaz muy consistente, transición fácil para usuarios de svn
Puede hacer la mayoría de las cosas que Git puede hacer también, 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 de selenic.

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

Reducción de la fricción:

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

Obtenga un curso introductorio de git para todo el equipo. Esto debe incluir solo lo básico y algunos ejercicios (¡importante!).
Convierta el repositorio maestro a svn y deje que las "estrellas jóvenes" 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 seguir usando git para sus propios repositorios.

Para ser sincero, creo que realmente tienes un problema de personas en lugar de una herramienta. ¿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 un tiempo en Integración Continua. Como mencioné anteriormente, independientemente del tipo de VCS que use, nunca hay un reemplazo para CI. Usted afirmó que hay personas que empujan a la basura al repositorio maestro: pídales que arreglen su basura mientras suena una alerta roja y los culpa por romper la compilación (o por no cumplir con una métrica de calidad o lo que sea).

En cuanto a los puntos 3 y 4 (por usuario, por sección, permisos por rama), eche un vistazo a gitolite (cubierto en el libro de Pro Git: gitolite ).

Política o no, Git es tan buena elección de un DCVS como cualquiera. Como cualquier herramienta poderosa, vale la pena pasar un poco de tiempo por adelantado para entender cómo está diseñada la herramienta para funcionar, y, para este fin, recomiendo encarecidamente el libro Pro Git. Un par de horas con esto ahorrará mucha frustración en el largo plazo.

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

En general, deseo encarecidamente que elija una herramienta que admita un control de acceso detallado en: - ramas (para segregar las ramas de versiones estables con estricta seguridad del tema, ramas que necesitan más agilidad y flexibilidad) - cumplimiento de la identidad (autor / confirmador) ) Esto es CLAVE para SOX - restricciones de comandos git - auditoría de seguimiento. Esto es CLAVE para SOX

Los que he utilizado con éxito con esas características son:

Gerrit Code Review (http://code.google.com/p/gerrit/)
GitEnterprise (http://gitenterprise.com)
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 hay un conjunto limitado de opciones que usted tiene dictadas por las Políticas de empresa sobre seguridad de la empresa.

Espero que esto ayude.

Luca.

Estoy respondiendo esta pregunta en función de mi experiencia como gerente de desarrollo en una gran empresa de telecomunicaciones, donde adoptamos Git en 2010

Aquí tienes un conjunto bastante diferente de problemas:

flujos de trabajo
herramientas de cliente
control de acceso al servidor e integración

Flujos de trabajo

Hemos adoptado 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 construcciones oficiales que se toman a través del proceso de entrega (que, en nuestro caso, se compone de tres niveles de prueba y dos implementaciones). Cada desarrollador maneja su propio repositorio, y trabajamos en función de cada rama.

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 plugin Git , sin ninguna otra cosa. Además, la mayoría de los desarrolladores de Linux están utilizando CLI git client, sin ningún problema. Algunos desarrolladores de Mac están utilizando con éxito Tower Git . Tenga en cuenta que ninguno de estos clientes puede evitar que el usuario "desordene" con el repositorio central: se necesita un mecanismo de control del lado del servidor

Control de acceso al servidor e integración

Si quieres evitar que los desarrolladores "arruinen" tu repositorio de Git, realmente debes elegir una solución que:

expone una interfaz de administrador web decente para hacer cada operación
le permite hacer cumplir las identidades de los usuarios (el uso de un repositorio "simple" de Git es extremadamente fácil de comprometer en nombre de otra persona)
le proporciona una seguridad detallada (para que, por ejemplo, pueda evitar FORCE-PUSH y configurar algunas ramas para que sean leídas solo 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 a veces es muy importante para grandes corporaciones)

No hay tantas soluciones listas para usar del lado del servidor que puedan ayudarlo, le sugiero que consulte uno de estos:

Gitorious : puede proporcionar seguridad de nivel de acceso básico, pero carece de permisos precisos de control de fábrica, por lo que probablemente tenga que hacer algunos códigos para manejar escenarios como permisos de nivel de rama. También carece de integración con los mecanismos de autenticación corporativos existentes
GitHub Enterprise: recientemente publicado por GitHub, presenta GitHub en su empresa. Carece de cumplimiento SOX y seguridad de grano fino
http://code.google.com/p/gerrit/ : puede proporcionar seguridad e integración de nivel de acceso fino con sistemas corporativos de autenticación, 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 de nivel de sucursal, SSO, cumplimiento con SOX, administración basada en web completa. Recientemente también se ha integrado con Gerrit, por lo que también te proporciona una instancia completa de Gerrit

¡Espero que esto ayude!

GUI: Por el momento, TortoiseGit v1.7.6 debería estar 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 ... Admite x64 nativamente también

Git permite crear ramas privadas. Esto alienta a los desarrolladores a comprometerse a menudo para desglosar las modificaciones en pequeños compromisos. Cuando el desarrollador está listo para publicar sus cambios, empuja al servidor central. Él puede hacer uso de scripts de precompromiso para verificar su código si es necesario.

Más adecuado para el desarrollo colaborativo que la gitosis o gitolita pero de 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.

NXP está administrando 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

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 así y lo recomiendo encarecidamente. La pieza de integración tiene que hacerse sin importar qué y es mucho más barato hacerlo antes y con más frecuencia.

Parece que su problema es que no ha decidido o 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 estableces reglas que todos deben seguir, entonces terminarás con un desastre. Recomendaría el flujo de trabajo de dictador y 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 por Mark Derricutt .

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 arruinar el maestro, simplemente lo eliminamos. En su lugar, preparamos todas las versiones fusionando las ramas que se seleccionan para probar y etiquetar 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 la versión realiza la fusión.

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

Como una ventaja 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 la cantidad de código que se agregó silenciosamente al proyecto anteriormente.

El proceso de revisión comienza cuando el propietario de la sucursal envía el diferencial a la placa 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) bajo "para revisión", o si es parte de un usuario completo historia, mueva toda la tarjeta de historia a "para revisión" y ponga la postulación en eso. El administrador de relaciones es el que mueve las tarjetas y las publicaciones para que estén "listas 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 combinació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 un lanzamiento 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 elemento primario común que facilita el manejo de las fusiones.

Recomiendo encarecidamente http://code.google.com/p/gerrit/ para el trabajo empresarial. Le brinda control de acceso más un flujo de trabajo basado en revisión incorporado. 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 cambios mientras todavía están bajo revisión; es una configuración realmente impresionante.

Si decides usar gerrit, te recomiendo tratar de mantener una historia bastante lineal, no una historia ramificada como la de algunos tipos de código abierto como. Gerrit lo define como "permitir cambios rápidos solo". Luego puede usar la bifurcación y la fusión en más de la forma en que está acostumbrado, para lanzamientos y demás.

Soy el ingeniero de SCM para una organización de desarrollo razonablemente grande, y hemos convertido a git de svn en el último año más o menos. Lo usamos de forma centralizada.

Usamos gitosis para alojar los repositorios. Rompimos nuestros repositorios svn monolíticos en muchos repositorios git más pequeños ya que la unidad de ramificación de git es básicamente el repositorio. (Hay formas de gitolite , 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 te 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 para una interfaz web.

En cuanto a algunas de sus preocupaciones específicas:

fusiones: puede usar 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; puedes verificar la fusión antes de presionar cualquier cosa.
GUI: tenemos algunas personas que usan TortoiseGit pero realmente no lo recomiendo; parece interactuar de maneras extrañas con la línea de comando. Tengo que aceptar que esta es un área que necesita mejoras. (Dicho esto, no soy partidario de las GUI para el control de versiones en general).
Ramas de seguimiento de grupos pequeños: si utiliza algo que proporcione ACL de grano fino como gitolita, es bastante fácil hacer esto, pero también puede crear una rama compartida conectando repositorios locales de varios desarrolladores: un repositorio 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 por el 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 etapas para revisar el código y compartir el código entre grupos pequeños. También se alienta a muchas personas a comenzar a rastrear sus scripts personales, etc., porque es muy fácil crear un repositorio.

Instale una interfaz web decente, como GitHub
Manténgase en un modelo relativamente centralizado (inicialmente) para mantener a las personas cómodas.
Ejecute una compilación de integración continua para cada rama compartida.
Comparte un buen conjunto de opciones globales de configuración de git.
Integra git en tu shell, con finalización de bash, y un prompt con la rama actual.
Pruebe la Integración Git de IntelliJ como una herramienta de fusión.
Asegúrese de .gitignore según corresponda.