È mai OK impegnare il codice non funzionante?

È una buona idea richiedere il commit solo del codice funzionante?

Questo commit non ha bisogno di lasciare il repository in uno stato funzionante come:

• ... siamo nelle prime fasi di progettazione, il codice non è ancora stabile.
• ... sei l'unico sviluppatore del progetto. Sai perché le cose non funzionano. Inoltre, non stai fermando il lavoro di nessuno commettendo un codice non funzionante.
• ... il codice attualmente non funziona. Faremo un grande cambiamento. Impegniamoci, per avere un punto su cui tornare se le cose si mettono male.

• ... la catena è lunga, nessun problema se esiste un codice non funzionante nel ramo locale. ie

  1. file locali
  2. area di sosta
  3. si impegna nella filiale locale
  4. si impegna nel ramo delle funzionalità personali remote
  5. unire con il developramo remoto
  6. unire con il masterramo remoto
  7. unire con il releaseramo remoto

• ... impegnarsi presto, impegnarsi spesso.

Quindi, nella domanda sopra collegata, la maggior parte delle risposte afferma che il commit di codice non compilabile non è un problema nei rami locali e delle funzionalità. Perché? Qual è il valore di un commit non funzionante?

Aggiunto: ci sono un paio di commenti molto votati, che dicono che su un locale si può fare quello che si vuole. Tuttavia, non mi interessa il lato tecnico della domanda. Piuttosto, vorrei imparare le migliori pratiche: le abitudini, che le persone che hanno lavorato per molti anni nel settore, hanno perseguitato in modo più produttivo.

Sono stupito dalla grande quantità di grandi risposte! Mi portano alla conclusione che non sono abbastanza esperto nell'uso dei rami per organizzare il mio codice.

Una delle filosofie di ramificazione (sezione Sviluppare la strategia di ramificazione e la politica di codeline in Strategie di ramificazione avanzate di SCM - leggi anche Le migliori pratiche di Perforce , è un pdf ma entra in alcuni altri dettagli) è che ti ramifichi su una politica incompatibile.

Una politica di codeline specifica l'uso corretto e i check-in consentiti per la codeline ed è il manuale dell'utente essenziale per SCM codeline. Ad esempio, la politica di una codeline di sviluppo dovrebbe dichiarare che non è per il rilascio; allo stesso modo, la politica di una codeline di rilascio dovrebbe limitare le modifiche alle correzioni di bug approvate. La politica può anche descrivere come documentare le modifiche in fase di check-in, quale revisione è necessaria, quali test sono richiesti e le aspettative di stabilità del codice dopo i check-in. Una politica è un componente critico per un processo di sviluppo software documentato e applicabile e una codeline senza politica, dal punto di vista di SCM, è fuori controllo.

(dalle best practice di Perforce)

Supponiamo di avere i rami 'release' (o 'master') da cui viene creata una release e 'trunk' (o 'dev') in cui gli sviluppatori effettuano il check in nel codice di lavoro. Queste sono le politiche delle filiali. Notare che il 'codice di lavoro' fa parte della politica del ramo 'dev', non si dovrebbe mai commettere codice rotto nel ramo dev. Spesso ci sono cose come i server CI collegati a questi rami e il check-in del codice non funzionante in dev potrebbe rovinare il ramo di tutti e spezzare la build.

Tuttavia, ci sono momenti in cui è opportuno archiviare il codice parziale che non funziona. In questi casi, si dovrebbe ramificare - una politica incompatibile con il trunk. In questo nuovo ramo, si può decidere la politica ('il codice non funzionante è ok') e quindi eseguire il commit del codice.

Esiste una semplice regola per determinare se una codeline deve essere ramificata: dovrebbe essere ramificata quando i suoi utenti necessitano di criteri di check-in diversi. Ad esempio, un gruppo di rilascio di prodotti potrebbe aver bisogno di una politica di check-in che imponga test rigorosi, mentre un team di sviluppo potrebbe aver bisogno di una politica che consenta check-in frequenti di modifiche parzialmente testate. Questa divergenza politica richiede un ramo di codeline. Quando un gruppo di sviluppo non desidera vederne un altro

(dalle best practice di Perforce)

Renditi conto che questo proviene da un SCM basato su server centrale con una forte mentalità aziendale. L'idea di base è ancora buona. Questi sono spesso considerati implicitamente: non si registra nel codice di sviluppo non testato nel ramo di rilascio. Questa è una politica.

Quindi ramo, dire che questo ramo può avere un codice rotto e impegnarsi.

Una delle filosofie suggerite da Linus Torvalds è che la programmazione creativa dovrebbe essere come una serie di esperimenti. Hai un'idea e seguila. Non sempre funziona, ma almeno ci hai provato. Vuoi incoraggiare gli sviluppatori a provare idee creative e, per farlo, deve essere economico provare quell'esperimento e economico recuperare. Questo è il vero potere di git che si impegna a essere così economico (facile e veloce). Apre questo paradigma creativo che consente agli sviluppatori di provare cose che altrimenti non potrebbero avere. Questa è la liberazione di git.

Sì, purché non sia un ramo di rilascio.

Nei rami personali, tutto va e può quindi essere scartato se l'esperimento non ha funzionato. Questo è uno dei principali vantaggi di DVCS: la libertà

Il valore del commit del codice non funzionante ?: collaborazione e sperimentazione

Sì, è OK ed è qualcosa che faccio molto.

Il punto di commettere codice non compilabile (almeno nelle filiali) è che a volte il tuo codice è un work-in-progress, ma che il lavoro svolto finora vale la pena salvare e / o condividere con altri

Le mie pratiche sono:

• scrivi prima i test
• gli commit di wip (work-in-progress) sono buoni
• commettere spesso (più di un giorno) e all'inizio (salvare i passaggi "funzionanti")
• spingere dopo ogni commit (nel caso in cui il disco rigido si blocchi / il bus ti colpisca).
• lavora sempre prima nei rami
• quando possibile, unire solo il codice di lavoro al master
• rebase interattivo in git per schiacciare i panni prima dell'unione principale

Il problema principale e forse quello su cui stai toccando è quando hai una funzionalità che funziona fondamentalmente ed è fortemente necessaria all'azienda (e quindi deve essere in "master") ma ha alcuni test falliti. Un'opzione qui potrebbe essere quella di fare un test in sospeso che ti consente di andare avanti per ora. Tuttavia, questo è irto di pericoli poiché il test potrebbe non essere mai risolto e potrebbe impostare uno schema in altre aree di semplicemente "in attesa" di test rotti invece di risolverli.

Un'altra opzione sarebbe quella di utilizzare temporaneamente e distribuire il ramo. Questo può aiutare in determinate situazioni, ma generalmente non è raccomandato e non è sostenibile.

Forse l'opzione migliore è fondamentalmente adottare un approccio più professionale allo sviluppo del software e richiedere davvero test di funzionamento per qualsiasi codice impegnato. Questa è spesso la parte "difficile" dello sviluppo del software, non la codifica che molte persone immaginano. Un approccio migliore richiederà probabilmente migliori stime iniziali, allocazione delle risorse, impostazione delle priorità, ecc., Inoltre, durante lo sviluppo Agile, concedendo abbastanza tempo e usando una disciplina sufficiente per risolvere eventuali problemi sia nel momento in cui si verificano che durante le sessioni di preparazione della persona.

Concentrati su ciò che significa "fatto": significa che il codice E i test sono scritti, sono stati rifattorizzati e funzionano. Se senti commenti come "per lo più fatto, devi solo scrivere / correggere / refactor test, quindi NON è fatto. Dire che una funzione è fatta senza che sia tecnicamente completa è uno degli errori più comuni dei programmatori junior.

Il valore di ogni commit, interrotto o meno, è che il codice è stato assegnato a un server. In ambienti professionali, quel server è sicuro, ridondante ed esegue backup. Se lavoro tutto il giorno, il commit è una forma per assicurarsi che il mio codice sopravviva a qualunque cosa accada alla mia macchina locale. I dischi rigidi muoiono. I laptop vengono persi o rubati. I backup del server repository saranno disponibili anche se l'edificio viene distrutto.

Pensaci in questo modo. Come sviluppatore una delle cose più dirompenti che devi fare è impedire ad altri sviluppatori del tuo team di svolgere i loro compiti.

La filosofia del solo commit del codice di lavoro proviene da team di sviluppo che lavorano sullo stesso singolo trunk nel repository. Adesso può sembrare una follia, ma 10 anni fa, questo era il modo normale di lavorare. Un ramo apparirà quando si desidera creare una versione stabile, ma il pensiero di uno sviluppatore che lavora in un ramo per implementare una nuova funzionalità era quasi sconosciuto.

Se il tuo ambiente significa che i tuoi commit non influenzano immediatamente altri sviluppatori, allora commetti spesso. ti dà più sicurezza nel tuo codice, facilitando il rollback di un errore di codice e molti sistemi di controllo del codice sorgente ti offrono una certa protezione del codice (anche se non tutti).

Ora, assicurandoti che le tue fusioni con le filiali condivise con altri sviluppatori funzionino e che qualsiasi codice che promuovi a questo livello venga compilato, superi tutti i test unitari e altri controlli di integrità basati su team ... è essenziale se non vuoi continua a comprare la birra nel pub ...

Prima di iniziare a diventare dogmatico su come lavorare con il controllo della versione, vale la pena pensare al motivo per cui stai lavorando con il controllo della versione.

L'impegno per il controllo della versione blocca lo stato del codice per riferimento futuro - tutto il resto non rientra in questo. Guardare diff e creare patch è solo vedere come il codice è cambiato tra le istantanee. Rami e tag sono solo modi di organizzare le istantanee. La condivisione del codice con altri sviluppatori sta semplicemente permettendo loro di guardare una particolare istantanea.

Quando dovresti impegnarti? Quando c'è una ragionevole possibilità, in futuro esaminerai lo stato del tuo codice (o il messaggio di commit che spiega una modifica).

Git ti offre molta flessibilità su come organizzare le tue istantanee. Non esiste un repository centrale, quindi puoi condividere il tuo codice con altri sviluppatori senza spingere il tuo stato nel repository "principale". Puoi facilmente creare, unire ed eliminare rami per isolare i dettagli di un insieme di stati dalla narrazione del codice principale. È possibile eseguire il commit a livello locale, per aiutarti a annullare un follow-up dello sviluppo corrente, quindi raggruppare tutto in un unico commit prima di inviarlo agli altri per vederlo. Puoi taggare revisioni specifiche in modo che siano facili da trovare in seguito.

BACIO . Ciò che funziona meglio per un singolo sviluppatore nelle prime fasi di sviluppo di un piccolo progetto sarà completamente diverso da quello che devi fare quando hai un centinaio di sviluppatori che lavorano su un sistema mission-critical decennale. In qualsiasi processo di sviluppo software, dovresti evitare di creare artefatti non necessari semplicemente perché qualcun altro ti ha detto di farlo.

Creazione / rilascio di rami

Non si dovrebbe mai commettere deliberatamente codice rotto in un ramo di build. Qualsiasi ramo in continua integrazione o da cui vengono realizzate versioni o build giornaliere dovrebbe essere sempre in uno stato potenzialmente rilasciabile.

Altre filiali: Salva spesso stato

Per i rami privati ​​o delle caratteristiche, gli obiettivi sono spesso diversi. Potrebbe essere auspicabile un check-in frequente del codice (funzionante o meno). In genere, ti consigliamo di impegnarti ogni volta che potresti aver bisogno di tornare allo stato attuale.

Considera questi esempi in cui lo stato salvato offre un vantaggio significativo:

• È possibile eseguire un commit prima di eseguire una ricerca e sostituzione globale in modo da poter ripristinare l'albero in una singola operazione se le cose vanno male.
• È possibile eseguire una serie di commit temporanei mentre si esegue il refactoring di un pezzo di codice complesso in modo da poter dividere in due o riavvolgere se si finisce per rompere qualcosa nel processo.
• È possibile eseguire un commit, avviare un nuovo ramo o creare un tag quando si desidera provare qualcosa di sperimentale mentre si è in grado di tornare allo stato dell'albero di lavoro corrente in qualsiasi momento.

Commettere una base di codice non funzionante va bene purché sia ​​locale.

Perché?

• È essenziale utilizzare il commit come punto di salvataggio nel proprio sviluppo
• Ti mostra un modello di pensiero usato durante lo sviluppo del prodotto.
• Non interrompe la collaborazione .

Tuttavia, quando esiste un team di programmatori, la filosofia della casa di programmazione è fondamentale e sostituisce i comportamenti di commit individuali. Alcune case di programmazione decidono di registrare tutti i progressi mentre altri decidono di impegnare solo il codice che risolve una funzione. In questo caso, il valore ( costo , dal punto di vista della gestione del software) di un commit interrotto è terribile:

1. il tempo impiegato per ulteriori funzionalità è ora impiegato per correggere errori ...
2. il taglio di sviluppo non è soddisfatto ...
3. il prodotto non viene spedito in tempo

Altri tre punti possono essere aggiunti a questi tre in cascata esponenzialmente i loro effetti in un crollo aziendale ... ovviamente, questo deve essere un effetto del cronico abituale impegno di codice errato.

Non penso che sia corretto commettere un codice non funzionante.

Cosa succede se

• È necessaria una correzione rapida urgente. La base di codice è in uno stato non funzionante. Sei costretto a ripristinare, correggere e distribuire.

• Qualcun altro inizia a lavorare nello stesso ramo senza sapere che hai commesso un codice non funzionante. Potrebbero inseguire un'aringa rossa pensando che i loro cambiamenti abbiano rotto qualcosa.

• Decidi di lasciare l'azienda, andare in vacanza o non puoi venire al lavoro per nessun motivo. I tuoi colleghi dovranno scavare in profondità per trovare ciò che è rotto e perché è stato commesso in uno stato rotto.

• Qualcuno distribuisce il tuo "codice non funzionante"? Questo può essere un "game over" se si lavora con dati personali o su un fornitore di pagamenti.

Rispondi a @WarrenT

Concordo con te sul fatto che in un mondo ideale in cui tutti lavorano in un ramo di funzioni, il commit di codice non funzionante potrebbe funzionare. Ho lavorato su progetti di grandi dimensioni e anche allora ci sono stati casi in cui più persone hanno dovuto lavorare in un singolo ramo di funzioni. Ho anche visto persone impegnare il codice "non funzionante" nella filiale principale perché il rilascio era a distanza di settimane e hanno pianificato di risolverlo il giorno successivo. Tutte queste cose sono candidate per un disastro e credo fermamente che dovrebbero essere evitate a tutti i costi.

Alcune domande per aiutarti a determinare se è corretto eseguire il commit di codice non funzionante:

1. Stai lavorando troppo?
2. I tuoi compagni di squadra rompono costantemente la build?
3. La tua base di codice è un casino e apparentemente non può andare peggio?

Se dici di sì a una delle precedenti, allora sì, va bene impegnare il codice non funzionante.

Ricorda solo di ripararlo il prima possibile, coprilo con tutti i test unitari applicabili e scusati per aver rotto la build.