GIT e diverse versioni di un progetto: quali sono le migliori pratiche?

Naviga le tue risposte
3

Sono molto nuovo nell'usare GIT come sistema di controllo delle versioni e nonostante molte ricerche, non riesco a capire come gestire il mio scenario.

Ho questo progetto web che deve essere sviluppato in due versioni:

  • il primo è una versione generale utilizzata per le demo
  • il secondo è una versione personalizzata per il mio cliente.

Per ora, la seconda versione differisce in cose minori, principalmente nel branding (cioè icone, alcuni titoli) e nelle connessioni al database.

L'idea è di migliorare il suo codice con suggerimenti e casi d'uso reali forniti dal client e, mentre avanziamo con correzioni di bug e nuove funzionalità, portiamo le modifiche alla "versione generale / senza marchio" - mantenendo però quelle differenze minori.

In futuro la versione "generale" potrebbe essere biforcata e potenziata di più con alcune funzioni indipendenti.

Le filiali sono un modo utile per gestire questo scenario? Penso che non lo siano, in quanto (almeno così ho capito) sono più intenzionati a rendere le modifiche da unire a breve o medio termine.

    
posta Cranio 23.11.2013 - 11:19
fonte

2 risposte

2

Dai un'occhiata qui:

link

Sebbene la domanda sia in qualche modo diversa, le risposte fornite da me e da altri spiegano come è possibile creare 2 versioni git separate / locali dello stesso sistema.

In base a quello che stai cercando di fare, vorrei pensare a uno scenario "Master / Slave", dove la demo (= Master) è dove la maggior parte del lavoro sarà fatto. Puoi quindi inserire la demo in una cartella separata ed eseguire git su di essa, dove puoi lavorare su di essa (ovvero dovrai vedere .git in ogni cartella personalizzata in cui viene eseguito il lavoro)

Ora, quando si aggiorna la demo e si desidera vedere questi aggiornamenti nel lavoro personalizzato "slave", sarà necessario unire il nuovo "master" con lo "slave" sul lavoro personalizzato (= slave) cartella.

In questo modo:

  • Il progetto demo rimane sempre una demo
  • Il lavoro personalizzato viene tenuto separato
  • Puoi creare tutte le diverse usanze che vuoi, ognuna con le sue controllo della propria versione
  • Puoi unire il lavoro demo aggiornato a ogni personalizzato, senza mescolare la demo di base (è necessario ricordare e imparare come fondersi sullo schiavo)

Dai un'occhiata a questo video per l'utilizzo di git: link

Qualcuno una volta me lo ha riferito per aver imparato git e l'ho trovato molto utile, ecco perché ti sto riferendo a te.

    
risposta data 23.11.2013 - 16:00
fonte
0

Spingi / tira e forca ...

Dopo aver riflettuto su questo per un po ', credo che il modello di "forking" - con un sistema push / pull per caratteristiche specifiche che si desidera migrare - potrebbe essere la soluzione migliore.

È questo schema che viene usato da grandi comunità open source per avere un singolo 'master' (copia ufficiale?) e molti molti rami di sviluppo / repository ecc.

È possibile farlo usando solo git (ad es. aggiungendo un telecomando a monte e anche questo ). È estremamente semplice farlo in Github, quindi per semplicità descriverò solo il flusso di lavoro di Github.

Impostazioni

  1. Crei il tuo repository "principale"
    • questa è la tua copia "lucidata" / "demo
  2. Tu " fork " questo repository
    • questa è la tua copia di "sviluppo"

Flusso di lavoro di sviluppo:

Si sviluppa in questo secondo repository, quindi quando si è pronti a "spingere" le funzionalità nel proprio repository "demo", è possibile inviare un rich request dal repository di sviluppo (contenente le modifiche desiderate) al repository demo.

Filiali?

Tutto questo può essere fatto tramite rami però, almeno nella mia mente, preferisco mantenere i due molto più distinti.

    
risposta data 14.12.2013 - 15:28
fonte

Leggi altre domande sui tag

Scegliere una lingua ubiquitaria attraverso diversi contesti limitati Come integrare un framework di test dell'unità JavaScript basato su browser nel mio flusso di lavoro?