Organización de directory en GIT

Soy novato de que GIT haya cambiado de SVN recientemente, me enfrenta a un problema sobre cuál sería la mejor manera de organizar todos mis files de proyecto en GIT.

Mis proyectos generalmente consisten en cuatro types de datos, a saber.

  1. Aplicación (contiene files relacionados con la aplicación web)
  2. Diseño (contiene files PSD proporcionados por el diseñador)
  3. Plantilla (contiene files HTML / CSS proporcionados por el desarrollador front-end)
  4. Documento (contiene files relacionados con la documentation del proyecto y proporcionado por el cliente)

En SVN solía crear los cuatro directorys mencionados anteriormente en la raíz y le pedía al miembro del equipo respectivo que revisara el directory específico como lo que necesitaban.

Por ejemplo

  • El diseñador de UI necesita acceder al directory 'Diseño' solamente.
  • El equipo frontend necesita acceso al directory 'Plantilla y layout' solamente.
  • El progtwigdor de backend solo necesita acceder al directory 'Plantilla y Aplicación'.
  • El administrador necesita acceso a todos los directorys.

En SVN fue bastante fácil lograr esto, ya que simplemente revisaba el directory deseado y seguía cometiendo lo mismo para que los cambios tuvieran efecto, pero es diferente en GIT, ya que tengo que aprender que no es posible clonar uno directory específico dentro del repository.

Me gustaría seguir la misma práctica con GIT y quiero que el equipo dé acceso a los resources que se necesitan para ellos y no necesariamente a todos.

Como GIT no me permitirá clonar un directory específico, pensé que podría estar creando diferentes twigs y almacenarlas en consecuencia puede ser una buena idea. ¿O puedo hacer una bifurcación para cada tipo individual de datos?

No me molestan los permissions si acceden a qué, está bien que el diseñador tenga acceso al directory de la Aplicación o del Documento, el único punto es que no quiero que todos clonen todo el repository ya que no tiene sentido para cada equipo miembro para download todo lo que no requieren. y de todos modos también se sumrá al time de descarga / carga, ya que en promedio el directory de layout solo consta de aproximadamente 300-400 mb.

Por favor, arroje algo de luz sobre cuál será la mejor manera de manejar esa situación?

PD: estoy usando bitbucket para repository

Gracias

En function de su información, sugeriría una de dos opciones:

  1. Tener cada una de las 4 "áreas de concentración" diferentes en su propio repository o
  2. Tenga cada una de sus áreas de concentración en una twig, todas en el mismo repository.

Yo prefiero el primero, porque sería más fácil de manejar. Solo crea nombres de repository como "proyecto-aplicación", "layout de proyecto", etc.

Si elige tener una sucursal por grupo, deberá establecer sucursales de seguimiento remoto para cada una de las sucursales.

Con sus repositorys individuales, solo tendrá que preocuparse por las sucursales de seguimiento remoto si alguien inicia un desarrollo a largo ploop en una de las sucursales y necesita que otros queueboren.

Incluso puede replicar la organización de SVN (lo encuentro útil), crear un / dir en cada uno de los clientes y luego solo verificar los repositorys que necesita con su nombre "base", como

mkdir my_project cd my_project git clone https://me@bitbucket.org/me/my_project-app.git app git clone https://me@bitbucket.org/me/my_project-design.git design 

y así sucesivamente … Entonces su estructura dir será igual a la que tenía en SVN, con / my_project / app, / my_project / design, etc.

Por lo tanto, tendrá repositorys locales individuales para cada una de sus áreas de enfoque.

No creo que esto sea posible directamente con git, sin embargo, hay 2 opciones:

  • Use una twig separada para cada componente
  • Crea un repository separado para cada componente.

Recomiendo crear un repository separado ya que la ramificación socavaría la ramificación real. Por ejemplo, si quiere ramificar cada componente para un "MYSITE_V2", terminaría creando una twig de cada twig. Podría ser desorderado.

Una tercera opción es aceptar esta limitación. Si sus desarrolladores solo necesitan clonar el repository una vez y luego empujan / arrastran los cambios, la preocupación del ancho de banda se mitiga. Solo prepárelos para comprender que su trabajo se encuentra en un subdirectory del repository. Ellos entenderán.