la synchronisation des variations sur un dépôt git

Question

J'essaie de comprendre comment (si possible) configurer plusieurs référentiels git pour qu'ils se comportent d'une manière spécifique. Fondamentalement, nous avons plusieurs référentiels pour plusieurs clients, mais ils sont destinés à tous partager un répertoire système. Lorsqu'une modification est apportée au répertoire système pour un client, elle doit être effectuée dans le répertoire système de tous les clients. Maintenant, pour la complication, nous avons plusieurs environnements que nous utilisons pour un système de développement CI. Nous disposons actuellement d'un environnement de production, d'un environnement client rev, d'un environnement qa et d'un environnement de développement. Ils se traduisent aisément en différentes branches car cela signifie que lorsqu'un flux de travail est approuvé pour l'environnement suivant, nous pouvons simplement fusionner cette branche de flux de travail dans la branche d'environnement appropriée et obtenir uniquement les modifications apportées à ce flux dans cet environnement. Le problème est que notre structure de code est configurée de manière à avoir un répertoire système qui est notre code de base, un répertoire personnalisé qui a un code spécifique au client (y compris les fichiers qui sont utilisés pour remplacer les fichiers dans le code système) et un répertoire de configuration spécifique au client. Notez que nous ne sommes pas sur un système orienté objet qui rend le développement encore plus compliqué car il n'y a pas d'héritage ou d'extensions pour faciliter les personnalisations.

Notre objectif est de convertir ce système de développement en GIT. Le problème que nous avons est de maintenir ce répertoire système partagé. Nous avons essayé des sous-modules, mais les sous-modules nécessitent beaucoup d'entretien pour éviter de les écraser ou de les déformer et ne fonctionnent pas aussi bien avec les branches d'environnement permanentes à cause de la quantité de travail fastidieuse. au commit principal de la branche qa dans le sous-module du système et non à un commit principal dans une branche WF. Notre IDE actuel est eclipse qui n'a pas d'intégration de sous-arbre (bien que ce que j'ai lu des sous-arbres, c'est qu'ils peuvent être aussi compliqués que des sous-modules). Ce dont nous avons vraiment besoin, ce sont des branches parallèles à travers plusieurs référentiels qui sont propagés. Ainsi, par exemple, si je crée une branche de flux de travail dans un référentiel client, une branche WF est créée dans le système repo et dans tous les autres clients repos. Et quand j'effectue une modification et fusionne ce flux de travail en qa, la branche wf du repo système est également fusionnée dans la branche qa, mais uniquement avec les modifications apportées au dossier système, et non les modifications apportées aux répertoires custom et config.

Je me demandais s'il y avait une bonne structure pour faire quelque chose comme ça. Tout ce que j'ai lu sur d'autres sites et sources a dit que la solution est juste de ne pas le faire de cette façon, mais cette décision n'est pas prise par moi. Les plus hauts sont déterminés à garder notre système de développement actuel. Une idée que j'ai eu est de voir s'il y a un moyen de faire quelque chose comme un passthrough où nous créons un référentiel qui n'a que le module système. Ensuite, pour chaque client, nous clonons ce repo et ajoutons les répertoires custom et config. Ensuite, quand nous faisons du développement, nous clonons le repo de ce client. Je me demandais si par cette méthode, si nous faisions un changement et si nous nous engagions et si nous étions poussés vers l'amont, si cela poussait les changements tout au long du repo de haut niveau. Aussi, quand nous baissons les changements, si nous pouvions tirer tout le chemin du repo de haut niveau. De l'autre côté, il faudrait configurer .gitignore dans les clients repos de manière à ne pas ignorer les répertoires custom et config lors de la remontée de flux, mais en incluant les répertoires en aval.

Toutes les pensées à ce sujet seront appréciées. De plus, notre hôte de code est un serveur gitlab privé.

Désolé, c'est trop long, mais je pense que nous avons un système très unique (pas bon) qui nécessite un peu d'explication.

Future Git utilisateur

Answer 1

Cela semble plus comme un problème d'organisation et l'architecture que git question mais je vais lui donner un coup.

Plutôt que de créer une prise en pension, avez-vous envisagé de créer une branche pour chaque client, puis ne fusionnez/pull que vous avez besoin puis pousser.

Déploiement via git n'est pas recommandé, git est pas une bonne façon de déployer. Son design est ouvert, enregistre les changements et rend le partage de code facile, donc si quelqu'un commet accidentellement des accréditations, elles sont enregistrées pour toujours à moins que vous ne fassiez des choses folles (et ces choses folles vont casser le code pour tout le monde). La plupart des utilisateurs sensés utilisent git pour valider et partager leurs modifications, construire une branche spécifique dans un module/pkg/image/container/something-stable-et-constant et ensuite déployer ce module ailleurs vers leurs clients.

Si vous souhaitez toujours utiliser pour le déploiement, la caisse git-hooks. Vous pouvez configurer certains hooks (par exemple, update ou pre-receive) qui tirent automatiquement le code lorsque la branche est mise à jour.

Une autre alternative serait plus tout le répertoire partagé dans un service de stockage en nuage ou d'un serveur NoSQL basé sur des documents. Il vous aide à maintenir une source unique que tout le monde peut chercher. Ce ne sera pas parfait et la consistance éventuelle causera peu de problèmes ici et là, mais cela en vaudra la peine. Je déconseille seulement pour les cas où les fichiers étant sur le disque du client tout de suite est important.