Come aggiungere in modo pulito i commit di fatto dalla stessa funzione nell'albero di git

3

Sono uno dei due sviluppatori su un sistema. Faccio la maggior parte dei commit in questo periodo. Il mio attuale flusso di lavoro git è come tale:

  • c'è solo master branch (no develop / release)
  • Faccio un nuovo ramo quando voglio fare una funzione, fare molti commit, e poi quando ho finito, unisco quel ramo nuovamente in master , e di solito lo spingo in remoto.

... tranne, di solito non ho finito. Torno spesso ad alterare una cosa o l'altra e ogni volta penso che sia fatta, ma può essere 3-4 commit prima che io sia davvero fatto e passare a qualcos'altro.

problema

Il problema che ho ora è che .. la mia struttura di rami di funzionalità viene unita e spinta in master e master remoto, e poi mi rendo conto che non ho davvero finito con quella funzionalità, perché in I ho finito i tocchi che voglio aggiungere , dove i ritocchi finali possono essere solo cosmetici, o possono essere significativi, ma appartengono ancora a quella funzione su cui ho appena lavorato.

Cosa faccio adesso

Attualmente, quando ho commesse extra in questo modo, risolvo questo problema ripristinando la fusione e ricomposizione del mio ramo feature in master con i miei nuovi commit, e lo faccio in modo che l'albero git sembra pulito. Un ramo di funzionalità pulite derivava da master e si è reimmesso in esso. Quindi spingo - forza le mie modifiche all'origine, poiché la mia origine non vede molto traffico al momento, quindi posso quasi contare che le cose saranno al sicuro, o potrei persino parlare con altri dev se devo coordinarmi. Ma so che non è un buon modo per farlo in generale, in quanto riscrive ciò che altri potrebbero aver già fatto, causando potenziali problemi. E è successo anche con il mio dev, dove git doveva fare un'ulteriore strana fusione quando i nostri alberi si sono separati.

Altri modi per risolvere ciò che considero non così grandioso

  • Il modo migliore è quello di rendere tali commit extra direttamente sul ramo master , sia che si tratti di un'operazione di unione rapida, o meno. Non rende l'albero bello come nel mio attuale modo, sto risolvendo questo, ma poi non riscrive la cronologia.

  • Un altro modo è attendere . Forse aspettare 24 ore e non spingere le cose all'origine. In questo modo posso riscrivere le cose come ritengo opportuno. L'imbroglio di questo approccio è tempo sprecato in attesa, quando le persone potrebbero essere in attesa di una correzione ora.

  • Un altro modo è creare un nuovo ramo di funzionalità ogni volta che mi rendo conto di dover aggiustare qualcosa in più. Potrei finire con cose come feature-branch feature-branch-html-fix , feature-branch-checkbox-fix , e così via, tipo di inquinare il git tree in qualche modo.

C'è un modo per gestire ciò che sto cercando di fare senza gli svantaggi che ho descritto? Sto andando per una storia dall'aspetto pulito qui, ma forse ho bisogno di abbandonare questo obiettivo, se tecnicamente non è una possibilità.

Esempi di messaggi di commit successivi alla realtà

Main commits:  alter module behavior to give user more information

Qui pensavo di aver finito, check out, & unire per padroneggiare, poi oops, dimenticato questo (OFT):

OFT:  (enhancement) added better error messages

Ok, ora ho finito!

Successivamente, l'utente torna e chiede un miglioramento / funzionalità. Si scopre che un certo numero di input per un ordine può avere una revisione associata ad esso. Quindi sono davvero due numeri, non uno.

OFT:  (feature-add):  fix up order input to accept revisions

Ora ho finito ...

OFT:  (bug-fix) there was a bug with the two-number input method, fix SQL for that

ok ora ho finito ...

OFT:  (enhancement) oh wait, improved error messages again, for clarity!
    
posta Dennis 20.08.2014 - 20:22
fonte

1 risposta

6

Quando ti unisci in master , stai essenzialmente dichiarando "I'm done". È come lasciare la posta all'ufficio postale o firmare un contratto di locazione. Non puoi cambiare idea dopo la fusione (ovviamente, in realtà puoi , grazie alle meraviglie della tecnologia, è solo una cattiva etichetta quando collabori con gli altri).

Se ritieni di aver bisogno di aggiungere altro, allora quello che stai aggiungendo è:

  • Un miglioramento non essenziale, che significa che puoi trattarlo come una nuova filiale e lavorare da lì.
  • O una correzione di bug importante, che dovrebbe accadere molto raramente - questo è il motivo per cui si dovrebbero sempre eseguire i test prima di fondersi in master . In questo caso, assicurati di far sapere a tutti che master è stato risolto e risolvere rapidamente la situazione.

Se ritieni che la tua funzione abbia ancora bisogno di ulteriori revisioni, allora non fonderti in master !

Se per qualche motivo altri sviluppatori vogliono dare una sbirciatina a quello che stai facendo, potresti semplicemente spingere il ramo della funzione, o creare un branch temporaneo dedicato con tutte le avvertenze di essere "temporaneo" ".

(Naturalmente, non c'è nulla di sacro in master di per sé, è solo che per convenzione la maggior parte della gente si aspetta che sia una base stabile da cui tutti possono tirare.)

Nota che i rami non sono necessariamente correlati alle tue caratteristiche. Git è per la cronologia di tracciamento e quindi i commit non avvengono necessariamente in modo logico e pulito a volte.

    
risposta data 21.08.2014 - 04:49
fonte

Leggi altre domande sui tag