Un projet, plusieurs clients avec git?

Question

Je suis nouveau chez GIT et je ne sais pas encore à quel point cela répondra à mes besoins, mais cela semble impressionnant.

J'ai une seule application Web que j'utilise pour différents clients (django + javascript)

Je prévois d’utiliser GIT pour gérer ces différentes versions de clients en tant que branches. Chaque client peut avoir des fichiers, des dossiers et des paramètres personnalisés, des versions améliorées ... mais doit partager le même "noyau". Nous sommes une petite équipe et avons souscrit un compte github.

La branche est-elle le bon moyen de gérer ce cas?

À propos du fichier de paramètres, comment procéderiez-vous? Souhaitez-vous .gitignore le fichier de paramètres spécifique au client et ajoutez un fichier settings.xml.sample, par exemple le référentiel?

De même, existe-t-il un moyen d’empêcher la fusion de certains fichiers dans le fichier maître? (mais commité à la branche client). Par exemple, je souhaite enregistrer certaines données client dans la branche client, sans empêcher leur validation par le maître.

Le fichier .gitignore est-il spécifique à une branche? OUI

MODIFIER Après avoir lu toutes vos réponses (merci!), J'ai décidé de commencer par refactoriser ma structure de projet django afin d'isoler le noyau et mes différentes applications dans un sous-dossier apps. Faire cela rend le projet plus propre, et modifier le fichier .gitignore facilite l’utilisation des branches git pour gérer les différents clients et paramètres!

Ju.

Answer 1

En plus de la réponse de cpharmston, il semble que vous deviez procéder à une refactorisation afin de séparer ce qui est vraiment personnalisé pour chaque client et ce qui ne l’est pas. Ensuite, vous pouvez envisager d’ajouter des référentiels supplémentaires pour suivre les personnalisations de chaque client (dépôts entièrement nouveaux, pas de branches). Ensuite, votre déploiement peut extraire votre "noyau". de votre dépôt principal et des éléments spécifiques au client de ce dépôt.

Answer 2

Je n'utiliserais pas de branches pour accomplir ce que vous essayez de faire.

Dans le contrôle de source, les branches sont destinées à être utilisées pour des éléments destinés à être fusionnés dans le tronc. Par exemple, Alex Gaynor a passé son été de code sur une branche de Django permet de prendre en charge plusieurs bases de données , dans le but de les réintégrer dans la junk de Django.

Les extractions (ou clones , dans le cas de Git) pourraient mieux convenir à vos tentatives. faire. Vous créez un référentiel contenant tous les fichiers de base du projet (et, si vous le souhaitez, des fichiers .sample), puis clonez le référentiel dans les différents emplacements où vous souhaitez déployer le code. Créez ensuite manuellement les fichiers de configuration et de personnalisation à chaque déploiement (veillez à ne pas les ajouter au référentiel). Chaque fois que vous mettez à jour le code dans le référentiel, exécutez un pull sur chaque déploiement pour mettre à jour le code. Viola!

Answer 3

Matthew Talbert a raison, vous devez vraiment séparer les éléments personnalisés des éléments non personnalisés. Si vous pouvez refactoriser tout le code principal pour qu'il soit contenu dans un répertoire, vos clients peuvent l'utiliser comme sous-module git en lecture seule. L'avantage supplémentaire est que vous les verrouillez dans une version explicite du code principal. Cela signifie qu'ils devraient délibérément mettre à jour vers une révision plus récente, ce que vous voulez pour le code de production.

Answer 4

D’autres réponses sont exactes, à savoir que vous serez en meilleure forme pour la maintenance dans la mesure où vous séparez votre code principal du code personnalisé par client. Cependant, je vais rompre avec la foule et dire que si vous êtes incapable de le faire (par exemple, parce que vous devez ajouter des fonctionnalités supplémentaires au code principal pour un client donné), les branches DVCS fonctionneraient parfaitement pour ce que vous voulez faire. . Bien que je recommanderais probablement des branches par répertoire plutôt que des branches in-repo à cette fin (git peut également faire des branches par répertoire, ce n’est qu’un repo cloné qui diverge).

J'utilise hg, pas git, mais tous mes projets Django sont clonés à partir de la même base "modèle de projet". repo qui a des scripts utilitaires, un ensemble commun de base d’INSTALLED_APPS, etc. Cela signifie que lorsque je modifie ce modèle de projet, je peux facilement fusionner ces mises à jour communes dans des projets existants. Ce n'est pas exactement la même chose que ce que vous prévoyez, mais c'est la même chose. Vous devrez parfois gérer des conflits de fusion si vous modifiez la même zone de code dans le noyau que vous avez déjà personnalisée pour un client spécifique.

Answer 5

Après avoir lu toutes vos réponses (merci!), j’ai décidé de commencer par refactoriser ma structure de projet django afin d’isoler le noyau et mes différentes applications dans un sous-dossier apps. Faire cela rend le projet plus propre, et modifier le fichier .gitignore dans le fichier des différentes branches facilite l’utilisation de git branches pour gérer les différents clients et paramètres!