¿Usar un repositorio central va en contra del propósito de GIT?

Question

Si está en un entorno corporativo con muchas personas trabajando en una aplicación en particular, ¿va en contra de un control de versión distribuido ¿sistema para tener un repositorio central oficial?

A veces me cuesta entender el concepto de un sistema de control de versiones distribuido como GIT en un entorno corporativo. Si no tuviera un repositorio central, ¿no sería un PITA averiguar quién tenía la última versión actualizada para extraer, quién tiene la función x o la corrección de errores y que todos necesitan obtener, etc., etc.

¿Está frustrando el propósito de GIT para usarlo de manera similar a SVN , con un repositorio central del que todos empujan / extraen? Cada vez que pienso en hacer eso siento que me estoy perdiendo el punto de todo.

¿Podría alguien iluminarme?

Answer 1

No realmente. DCVS simplemente permite más libertad en cómo interactuar entre desarrolladores sin involucrar al repositorio central. El repositorio oficial solo es oficial por consenso . Linux también tiene un repositorio central, desde el cual el "oficial" se crean versiones de kernel, pero no existe una diferencia física entre el repositorio central, oficial y los repositorios del cliente, ya que está en VCS centralizado.

Answer 2

Probablemente esté pensando en las líneas de este diagrama:

??

Esto probablemente se verá como un caos proveniente de un CVCS. "Necesitamos un orden", ¿te oigo decir?

  

Si no tuviera un repositorio central, ¿no sería una PITA averiguar quién tenía la última versión actualizada para extraer, quién tiene la función x o la corrección de errores y que todos necesitan obtener, etc., etc. .

Sí A diferencia de un CVCS, no hay realmente una & # 8220; última versión & # 8221 ;. Si no hay una ubicación central, no sabe de inmediato si debe ver a Sue, Joe o Eve para la última versión. Una ubicación central ayuda a aclarar qué es lo último & # 8220; estable & # 8221; lanzamiento es.

Algo más parecido a esto:

??

También podría valer la pena señalar que podría haber más de un repositorio central percibido dependiendo de las competencias de los grupos de personas dentro de una organización.

Imagine un gerente de proyecto que gestiona múltiples equipos de desarrollo, cada equipo podría tener una "central" repositorio al que empujan. Cada semana, el gerente del proyecto podría llevar los cambios de cada equipo a su '' central '' repositorio, fusionarlos y empujarlos de vuelta a la "central" de sus equipos repositorios.

Probablemente este no sea un gran ejemplo (todavía estoy entendiendo todo esto también), pero ese es solo un gerente de proyecto. Agregue algunos proyectos / gerentes más y un equipo de control de calidad, entonces es posible que vea de dónde vengo ...

-

• Diagramas y un párrafo cortesía de un artículo de Kalid Azad

Answer 3

Con control de fuente distribuida, un "oficial" central el repositorio está establecido por la política, no por la arquitectura de la herramienta de control de origen.

Answer 4

Definitivamente no está frustrando el propósito de Git.

La ventaja de usar Git o cualquier otro DVCS incluso cuando hay un repositorio central y oficial es todavía que el control de fuente está descentralizado. Es decir, puede tomar su copia del repositorio, trabajar en su código y realizar una confirmación local cada pocos minutos si lo necesita. No tiene que preocuparse de que las confirmaciones estén en código a medio terminar que rompa la compilación, todo es local. (Y muy rápido)

Luego, cuando todo el trabajo está hecho, puede limpiar el historial y enviar los cambios completos al repositorio central en un estado homogéneo y limpio.

No creo que pueda subestimar la ventaja de separar la idea de "privado" se compromete y "público" empuja Permite realizar un seguimiento de los cambios a pesar de que usted es el único que se beneficia de una granularidad tan pequeña.

Answer 5

Si marca esta Presentación de Git , (diapositiva 475 y siguientes), un modelo de repositorio central es perfectamente compatible con Git.

Puede obligar a cualquiera que desee git push su desarrollo a hacer primero un git fetch + git merge primero, luego presione.

Eso no vence en absoluto el propósito de Git y garantiza que todos estén 'sincronizados' entre sí.

La diferencia con el "oficial" de Linus El repositorio mencionado por JesperE es que está gestionado por un flujo de trabajo diferente, a saber, un " Dictador y tenientes " modelo, donde el acceso de escritura (push) solo se otorga a Linus, y la lectura se otorga a cualquiera.

Ahora: " eso vence el punto de DVC " ?

No, todavía tiene repositorios distribuidos, uno para cada desarrollador, y pueden buscar / fusionarse entre sus propios repositorios, de acuerdo con su propio flujo de trabajo interno del equipo.
Sin embargo, si quieren contribuir al repositorio central, deben tener que estar al día con la última historia de ese repositorio.

Answer 6

Uno de los principales beneficios de DVCS es que puede obtener la última versión del repositorio 'oficial' y luego ser aventurero. Puede confirmar los cambios localmente y retroceder a voluntad. Esto también significa que incluso puede trabajar incluso sin acceso al repositorio central y aún tener los beneficios del control del código fuente.

Creo que con un poco de disciplina el modelo funciona muy bien. Este artículo explica bien los diversos modelos que podría adoptar

Answer 7

DVCS como Git no te obligan a usar un repositorio central. Por supuesto, es posible declarar un repositorio como & # 8220; central & # 8221; o & # 8220; oficial & # 8221; o lo que sea, y en el contexto de una empresa, un repositorio central tiene sentido & # 8212; si no es para el desarrollo, al menos para fines de copia de seguridad.