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!