In quali condizioni dovrei eseguire il rebase piuttosto che unire?

Naviga le tue risposte
1

Ecco, grosso modo, la nostra struttura di lavoro che usa git, per lo sviluppo web. Abbiamo un master branch e singoli o gruppi di lavoro sono fatti separatamente nelle filiali, quindi uniti in.

  1. Arriva un ticket (o più)
  2. Creiamo un ramo sul nostro repository di sviluppo locale e lo spingiamo all'origine.
  3. Fissiamo i ticket nel codice, eseguiamo il commit del lavoro e spingiamo all'origine.
  4. Una volta che siamo soddisfatti del nostro lavoro, trasciniamo il ramo in un repository sul nostro server UAT / Staging e lo controlliamo affinché il cliente possa esaminarlo.
  5. Il client approva il lavoro.
  6. Torniamo al nostro repository di sviluppo locale, controlliamo il master, uniamo il ramo e spingiamo all'origine.
  7. Creiamo un tag dal master in seguito.
  8. Quindi andiamo sul server live, tiriamo il master e spostiamo / aggiorniamo il tag su quello nuovo.

Siamo in 7, lavorando a circa 15 progetti circa nel corso dell'anno. In generale, una persona è sufficiente per lavorare su un progetto in qualsiasi momento, ma a volte due persone potrebbero lavorare in rami separati con l'obiettivo di unirsi al ramo principale più o meno nello stesso momento.

In generale, riteniamo che la fusione sia la migliore perché, come comprendo, conserva una cronologia dello sviluppo in relazione a ciò che è stato unito e quando. Considerando che rebase sembra distruggere completamente questo e linearizzare il registro principale.

Perché, se questa ipotesi è corretta, qualcuno vuole usare rebase? È solo per i progetti estremamente occupati che vengono costantemente ramificati e uniti e c'è bisogno di garantire che le unioni siano riuscite - così gli sviluppatori possono testare l'aggiunta di master al loro lavoro e risolvere i conflitti prima di unirli nuovamente?

    
posta njp 30.07.2013 - 13:24
fonte

1 risposta

1

rebase può essere utilizzato solo su lavori in corso che non sono stati ancora uniti (nemmeno nei tuoi colleghi.) Una volta che il lavoro è stato unito, non devi rebase (o modificare). creare confusione incredibile.

Per lavori in corso, tuttavia, la rifondazione è spesso appropriata. Viene utilizzato per mantenere le fusioni fuori dal lavoro in corso e per mantenere i lavori in corso organizzati in fasi logiche piuttosto che storiche. Che è utile se:

  1. Qualcuno revisionerà le modifiche prima di integrarle. Le modifiche più grandi sono molto più facili da rivedere in serie di passaggi logici, ma devono essere passaggi logici .
  2. Vuoi rivedere le modifiche da solo per assicurarti di non aver apportato modifiche non correlate o inappropriate.
  3. Hai alcune modifiche sperimentali tra le modifiche che devi integrare (il rebase -i ti consente di riordinare le modifiche).

(lo sviluppo di Linux includeva sempre recensioni che richiedevano le modifiche presentate nelle serie di patch, che è ciò che ispirava git rebase , specialmente quello interattivo)

    
risposta data 30.07.2013 - 13:29
fonte

Leggi altre domande sui tag

Cercando di creare un editor grafico personalizzato per un modello di dati usando HTML5 e SVG Vale la pena scrivere un test unitario per un DTO con i getter / setter di base? [duplicare]