Un progetto, più clienti con git?

Question

Sono nuovo di GIT e non so ancora quanto si adatterà alle mie esigenze, ma sembra impressionante.

Ho una singola webapp che utilizzo per clienti diversi (django + javascript)

Ho intenzione di utilizzare GIT per gestire le diverse versioni dei clienti come filiali. Ogni cliente può avere file, cartelle e impostazioni personalizzati, versioni migliorate ... ma dovrebbero condividere lo stesso "core". Siamo una piccola squadra e abbiamo creato un account github.

Il ramo è il buon modo per gestire questo caso?

Informazioni sul file delle impostazioni, come procederesti? Vuoi archiviare il file delle impostazioni specifico del cliente e aggiungere un file settings.xml.sample ad esempio il repository?

Inoltre, c'è un modo per impedire che alcuni file vengano uniti in master? (ma impegnato nella filiale del cliente). Ad esempio, mi piacerebbe salvare alcuni dati dei clienti nella succursale dei clienti, ma impedire di essere commessi come master.

Il file .gitignore è specifico del ramo? YES

Modifica Dopo aver letto tutte le risposte (grazie!) Ho deciso di refactoring la struttura del mio progetto django per isolare il core e le mie diverse app in una sottocartella di app. Fare questo rende un progetto più pulito e modificare il file .gitignore semplifica l'uso dei rami git per gestire i diversi clienti e impostazioni!

Ju.

Answer 1

Oltre alla risposta di cpharmston, sembra che tu debba fare un po 'di refactoring per separare ciò che è veramente personalizzato per ogni cliente e ciò che non lo è. Quindi puoi prendere in considerazione l'aggiunta di ulteriori repository per tenere traccia delle personalizzazioni per ciascun client (repository completamente nuovi, non filiali). Quindi la tua distribuzione può estrarre il tuo " core " dal tuo repository principale e le informazioni specifiche del client da quel repository.

Answer 2

Non userei i rami per realizzare ciò che stai cercando di fare.

Nel controllo del codice sorgente, i rami sono pensati per essere usati per cose che devono essere ricondotte nel trunk. Ad esempio, Alex Gaynor ha trascorso le sue estate del codice lavorando su una filiale di Django che consente il supporto per più database , con l'obiettivo di fonderlo nuovamente nel trunk Django.

Checkout (o cloni , nel caso di Git) potrebbero adattarsi meglio a ciò che stai provando fare. Dovresti creare un repository contenente tutti i file di base del progetto (e, se vuoi, file di esempio) e clonare il repository in tutte le varie posizioni in cui desideri distribuire il codice. Quindi creare manualmente i file di configurazione e personalizzazione ad ogni distribuzione (fare attenzione a non aggiungili al repository). Ogni volta che aggiorni il codice nel repository, esegui un pull su ogni distribuzione per aggiornare il codice. Viola!

Answer 3

Matthew Talbert ha ragione, devi davvero separare le cose personalizzate da quelle non personalizzate. Se riesci a refactificare tutto il codice principale in una directory, i tuoi clienti possono usarlo come sottomodulo git di sola lettura. Il vantaggio aggiuntivo è che li si blocca in una versione esplicita del codice principale. Ciò significa che dovrebbero aggiornare consapevolmente a una revisione più recente, che è ciò che si desidera per il codice di produzione.

Answer 4

Altre risposte sono esatte sul fatto che sarai nella forma migliore per la manutenzione nella misura in cui separerai il tuo codice principale dal codice personalizzato per cliente. Tuttavia, mi separerò dalla massa e dirò che se non sei in grado di farlo (ad esempio perché devi aggiungere funzionalità extra al codice core per un determinato client), i rami DVCS funzionerebbero bene per quello che vuoi fare . Anche se probabilmente consiglierei i rami per directory piuttosto che i rami in repo per questo scopo (git può fare anche rami per directory, non è altro che un repository clonato che diverge).

Uso hg, non git, ma tutti i miei progetti Django sono clonati dalla stessa base "modello di progetto". repository con script di utilità, un set comune di base di INSTALLED_APPS, ecc. Ciò significa che quando apporto modifiche a quel modello di progetto, posso facilmente unire tali aggiornamenti comuni in progetti esistenti. Questo non è esattamente lo stesso di quello che stai pianificando, ma è simile. Occasionalmente dovrai affrontare i conflitti di unione, se modifichi la stessa area di codice nel core che hai già personalizzato per un cliente specifico.

Answer 5

Dopo aver letto tutte le tue risposte (grazie!) ho deciso di refactoring la struttura del mio progetto django per isolare il core e le mie diverse app in una sottocartella di app. Fare questo rende un progetto più pulito e modificare il file .gitignore nel file dei rami differenti rende facile usare i rami git per gestire i diversi clienti e impostazioni!