Software a 2 versioni: il miglior approccio VCS?

Question

Suppongo che sarebbe meglio spiegare la mia situazione:

Sono in procinto di sviluppare alcuni software, e sono nella fase in cui mi piacerebbe dividere il mio progetto in due rami che differiscono per caratteristiche . Accade così che questa applicazione sia un'applicazione Android che distribuirò sul Market, che ha il vincolo che ogni app debba avere un identificatore di pacchetto univoco (ragionevole, no?).

Il mio attuale approccio è stato quello di clonare il repository git del mio progetto originale, ma questo causa problemi con i nomi dei pacchetti. Voglio che il sistema sia abbastanza robusto in modo che una correzione/nuova funzione su un ramo si unisca in un altro ramo, ma solo quando lo voglio.

Qualcuno ha qualche suggerimento?

Answer 1

Io stesso gestisco il caso esatto per un'app a pagamento e una versione di prova con lo stesso codice base. Sto usando SVN, ma qualsiasi software di controllo della versione che supporti la ramificazione funzionerebbe.

Ho creato un ramo per la versione di prova dal bagagliaio.

Quindi ho modificato il file AndroidManifest.xml della versione di prova per modificare il nome del pacchetto, aggiungendo .trial alla fine. Ho quindi dovuto anche aggiornare tutti i file java di attività per fare riferimento alla classe R corretta.

Il mio pacchetto app a pagamento è com.hewittsoft.baby
mio pacchetto di prova app è com.hewittsoft.baby.trial

Nelle mie attività sul ramo di prova che faccio questo

import com.hewittsoft.baby.trial.R; 

e questo fa sì che qualsiasi riferimento a R.id.textField (o qualsiasi altra cosa) funzioni.

Dopo aver eseguito questi passaggi, posso sviluppare il ramo principale e quindi unire eventuali modifiche nella versione di prova senza troppi problemi.

Answer 2

Se l'unico problema è un problema di gestione della confezione e rilascio, è possibile isolare tali passaggi (rinominare il pacchetto e verificarlo in un ambiente di destinazione) dal ciclo di storicizzazione all'interno di un repository Git.

Quindi è possibile andare avanti, separare lo sviluppo, una funzione per ramo, mantenendo gli stessi nomi di pacchetto per entrambi (in modo da unire facilmente le correzioni da una all'altra).
Tuttavia, per testare e distribuire una di queste due versioni, è possibile avere uno script che si occupa di rinominare i pacchetti, ricompilare, impacchettare (jar) e distribuire il risultato nell'ambiente di test di destinazione.

Answer 3

Un paio di ottimi articoli sulle strategie di ramificazione: http://codicesoftware.blogspot.com/2010/03/branching-strategies.html http://nvie.com/git-model