I check in nel Master Branch devono essere puliti?

Question

I check in nel Master Branch devono essere puliti?

#1 da (5 voti)
#2 da (0 voti)

1

Abbiamo avuto un dibattito sul nostro team su come dovrebbe essere pulito il ramo Master.

L'applicazione è scritta e gestita da due persone, me (uno sviluppatore) e un designer GUI / UX. Il progettista GUI / UX esegue molti prototipi (o esperimenti di tipo "sandbox") per testare o correggere vari problemi di layout in JS & CSS. Questo lavoro preliminare o provvisorio introduce un codice "sporco" come CSS inline, JS sparsi, formattazione scadente, ecc. Vorrebbe controllare direttamente in Master non appena funzionalmente i suoi obiettivi sono stati raggiunti, e io la fermo.

I miei check in Master sono molto puliti e faccio sempre una Diff per assicurarmi che siano definitivi, formattati e modularizzati. Pulisco le modifiche preliminari o provvisorie che dovevo fare per garantire che il Master fosse "ufficiale". Il Master dovrebbe essere sporco?

version-control development-process agile web-development

posta gene b. 23.01.2018 - 17:25

fonte

2 risposte

Leggi altre domande sui tag version-control development-process agile web-development

va bene che il team di sviluppo crei attività di refactoring nel backlog del prodotto? Esiste un modello di progettazione che posso utilizzare per semplificare molti metodi nidificati

score 5 · Answer 1

Questa è in definitiva una decisione che un team deve prendere in base agli standard di codifica e al ciclo di rilascio.

Se rilasci abbastanza raramente (ogni paio di sprint) l'argomento potrebbe essere fatto che il controllo in master per essere migliorato in un secondo momento sia ragionevole. Tuttavia assumendo alcune cose, preparerò una scatola di sapone:

Se:

Lavori in un ambiente in cui il master deve essere sempre pronto per la produzione (e può essere rilasciato in qualsiasi momento)
Hai la possibilità di effettuare il check-in senza passare al master (forse una copia git locale del repository principale) utilizzando un meccanismo di richiesta pull

Quindi suggerirei che qualsiasi codice presente nel ramo master dovrebbe essere pronto per la produzione. Questo include:

Chiaro e leggibile,
Unità correttamente testata,
Soddisfa tutti gli altri standard di codifica,
e costruisce!

Altrimenti potrebbe essere necessario implementare (al termine di un rilascio, sprint o una soluzione urgente) e il codice di scarsa qualità è nel ramo principale. Questo alla fine porterà a un codice che non migliorerà e al debito tecnico in futuro.

score 0 · Answer 2

Penso che tutti possiamo essere d'accordo sul fatto che il controllo del codice non funzionale sia una cosa brutta (tm)

Tuttavia, la tua definizione di "dirty" è piuttosto soggettiva.

Ti suggerisco di passare a gitflow, consentire a qualsiasi commit di disporre di rami. ma avere un processo di revisione PR / Code prima che il ramo della funzione possa essere unito allo sviluppo.

Inoltre, pensa e assicurati di non applicare regole più severe agli altri rispetto a te stesso.

È fin troppo facile concederti "Oh, ho bisogno di rispettare la scadenza / Quel trucco è accettabile / Deve essere fatto in quel modo perché ho cercato su Google per anni ma non sono riuscito a trovare una risposta" Quando stai recensendo il tuo codice e poi raccogliere gli altri su Pascal vs cammello caso