Crea un repository GIT separato per la pubblicazione con cronologia diversa?

3

Sto sviluppando un progetto, che sto spingendo al repository privato sul mio VPS. Tuttavia, mi piacerebbe pubblicarlo su GitHub.

Faccio molti commit (principalmente come backup) che non contengono l'implementazione completa della funzionalità. Non voglio includere la cronologia di questi commit nel repository pubblico.

Quindi, la cronologia privata sarà simile a:

  1. commit iniziale
  2. Parte Caratteristica A
  3. Parte Caratteristica A
  4. Parte Caratteristica A
  5. Caratteristica finita A
  6. Caratteristica della parte B
  7. Caratteristica finita B
  8. ... ecc.

E la cronologia desiderata del repository pubblico dovrebbe essere simile a:

  1. commit iniziale
  2. Funzione A
  3. Funzione B
  4. ... ecc.

E non deve esserci traccia di commit parziali fatti per il backup di sviluppo. Quindi tutti i componenti interni di un repository GIT potrebbero apparire come se ci fosse solo un commit di funzionalità , nessun commit parziale.

So che posso clonare i repository in cartelle diverse e copiare e incollare tra queste cartelle. Tuttavia, GIT è progettato per lo sviluppo distribuito. Quindi, mi chiedo se ci sia un modo più pulito e più simile a GIT per risolvere questo problema.

Come gestire repository separati con storie diverse?

Il primo commit su repo pubblico può essere completamente compresso, ma da allora mi piacerebbe avere una bella cronologia di commit nel repository pubblico.

    
posta kravemir 10.11.2015 - 17:46
fonte

2 risposte

3

Utilizza Flusso di lavoro di Gitflow

Seguendo questo modello, il ramo master contiene solo rilasci, il ramo develop contiene i commit WIP (work in progress) e feature branch per lo sviluppo delle funzionalità.

Il vantaggio principale di questo approccio è che se sviti e pubblichi un commit errato su develop sarai in grado di eseguire il rollback delle modifiche senza rovinare la cronologia della versione accessibile pubblicamente su master .

Quindi, questo non risponde alla tua domanda ...

Che ne dici di combinare le funzioni parziali in una singola funzione?

Semplice, prima di unire un ramo feature in develop schiaccia i commit usando il rebase interattivo.

git rebase -i feature-branch

Apparirà un editor e potrai cambiare i commit che vuoi schiacciare. Concatena anche i registri di commit in modo da poterli aggiungere tutti o parte di essi nel messaggio di commit schiacciato.

Nota: esistono molti modi per schiacciare la cronologia dei commit . IMHO, penso che il rebase interattivo sia il più diretto ma YMMV.

Quando sei pronto per un rilascio, crea semplicemente un ramo release da develop e unisci il ramo release a 'master.

Lo sviluppo di funzionalità può essere difficile perché un manutentore potrebbe richiedere a un contributore di apportare modifiche aggiuntive in modo frammentario prima di accettare una PR (richiesta di pull).

Utilizzando la strategia di cui sopra, il contributore avrà comunque una cronologia granulare contenente tutte le modifiche apportate alla funzionalità durante lo sviluppo. Ciò semplifica il rollback e / o il cherry-pick dei commit individualmente.

Nota: la capacità di selezionare i commit è estremamente preziosa se il contributore incontra dei conflitti di fusione complicati.

Se vuoi che le funzionalità si commettano in modo pulito, fai in modo che il contributore esegua lo schiacciamento delle modifiche come ultimo passaggio prima di un'unione.

    
risposta data 10.11.2015 - 23:35
fonte
0

Questo fa sorgere la domanda sul perché vuoi farlo, ma questo è il tuo problema. Ecco alcuni possibili approcci per farlo:

Filiali separate per le funzioni

  • Mantieni sincronizzato il tuo ramo principale con il master del repository pubblico
  • sviluppa ogni funzione nel tuo repository locale / privato, ma non sincronizzare questi rami con il repository pubblico
  • usa git merge --squash per unire questi rami come un singolo commit

Uso di repository differenti

  • Utilizza un repository per lo sviluppo pubblico e privato
  • sviluppare nel tuo repository privato
  • dopo che una funzione è terminata, usa git diff per creare un file .diff
  • applica tale diff utilizzando patch nel repository pubblico e conferma.
risposta data 10.11.2015 - 17:59
fonte

Leggi altre domande sui tag