it-swarm.it

Quali sono alcune buone pratiche prima di effettuare il check in del codice sorgente?

Il mio team utilizza Team Foundation Server per il controllo del codice sorgente e oggi ho corretto alcuni bug e l'applicazione test fumo prima di effettuare il check-in, ma ho dimenticato di commentare del codice. (Questo codice ha reso l'interfaccia utente un po 'strana.)

Voglio sapere quali sono le buone pratiche prima di effettuare il check-in del codice - Non voglio ripetere questo tipo di errore.

47
Anonymous

Una cosa che ho preso l'abitudine di fare è sempre guardare le differenze di ogni file che sto per fare il check-in, proprio prima di fare il check-in.

149
crudcore

Non devi mai effettuare il check-in del codice commentato. Se hai del codice che deve essere commentato prima del check-in, stai sbagliando.

Per quanto riguarda le regole:

  1. Ricevi le ultime
  2. Risolvi i conflitti di unione
  3. Costruire

    3.1 Correggere errori di compilazione

  4. Esegui test

    4.1 Correggere i test rotti

  5. Vai a 1 (fino a quando non c'è nulla di nuovo da ottenere)

Effettua il check-in solo quando tutti i passaggi sono completi.

Vedi check-in dance .


Altre buone pratiche:

  • Rivedere l'elenco dei file da archiviare per assicurarsi che siano i file previsti.
  • Rivedere le modifiche per ciascun file (eliminazioni/aggiunte/differenze)
63
Oded

Non sto provando a essere un eccessivo fanweasel qui, ma il presupposto in questa domanda (e tutte le risposte tranne una) si applica principalmente ai VCS centralizzati, come TFS, SVN, Perforce, ecc.
Abbastanza giusto, è ciò che utilizza l'OP.

D'altra parte, tuttavia, quando si utilizza DVCS (come Mercurial e Git), di solito non si deve attendere il check-in e la maggior parte delle cose menzionate nelle risposte - come diff, get latest, merge, ecc. - non sono necessarie . Anche cose come recensioni e test di codice sono meglio fare dopo il check-in (anche se forse prima di spingere, a seconda ...)
L'unica eccezione che ho visto qui (finora) è l'associazione con un oggetto di lavoro. Naturalmente, anche commentare il check-in è buono ...

20
AviD

Tre cose che non ho visto in altre risposte:

Includi nuovi file

  • Cerca nuovi file che non fanno parte della tua lista dei cambiamenti
  • Può essere specifico per gli SCM come Perforce: devi dirlo a tutto ciò che sta cambiando.

Ripristina file invariati

  • Odio quando guardo i cambiamenti degli altri e c'è un elenco di modifiche con nove file, ma solo tre di questi sono stati modificati.
  • Ripristino anche i file con spazi bianchi o modifiche altrimenti prive di significato.

Verifica il commit inviato

  • Assicurati che la build rimanga verde dopo il commit.
  • Avevo una seconda macchina che sincronizzavo, costruivo ed eseguivo dopo i miei commit, quindi se qualcosa fosse andato storto, avrei potuto facilmente saltare e sistemarlo.

Due cose quando uso Git:

Impegni atomici:

  • Mettere in scena solo modifiche funzionali individuali per il commit.
  • Impegnati il ​​più piccolo possibile. Renderli facili da correggere, ripristinare e capire.
  • Io uso git add --patch per dividere la mia modifica in più parti se necessario.

Visualizza le differenze durante il riepilogo

  • Controllo sempre con git commit --verbose così posso vedere una diff della mia modifica mentre sto digitando il mio messaggio di commit. (Oppure uso il mio patch git-vim per mostrare il diff.)
  • Ciò rende molto più semplice esaminare le modifiche e descrivere l'intero commit. Occasionalmente, in questa fase prendo cambiamenti non intenzionali. (Descrivere la modifica ti aiuta a pensarci.)
8
idbrii

Cerca e sostituisci le parolacce ;-)

7
Throwback1986

Alcuni elementi di "buone pratiche" che impongo sui server del mio team sono piuttosto semplici. Innanzitutto, prima di effettuare il check-in, dovresti sempre ottenere le ultime ed eseguire una build locale, per assicurarti che nessun altro abbia controllato qualcosa con cui il tuo codice si scontrerà. Inoltre, prenditi cura di eventuali conflitti di codice sul tuo computer locale, non sul server. Una volta che il tuo codice, con l'ultimo codice scaricato, è stato confermato per compilare e funzionare correttamente, sei pronto per il passaggio successivo. Esegui eventuali test automatici, quindi avvia il check-in per assicurarti che funzionino correttamente. Quindi, per essere sicuro, torna di recente.

È possibile, come amministratore TFS, imporre commenti su tutti i check-in. Consiglio di inserire sempre i commenti relativi al check-in per il proprio lavoro, indipendentemente dal fatto che venga applicato o meno. Se hai la possibilità di farlo, applicalo. Assicurati che i commenti siano, almeno, un riepilogo generale di ciò che hai modificato dall'ultima volta che hai eseguito il check-in del codice. In questo modo, se qualcosa va storto, puoi guardare attraverso i check-in e vedere, approssimativamente, ciò che è stato modificato in quel check-in. Rende molto più semplice il debug di una build non funzionante.

Inoltre, se disponi dei privilegi di amministratore di TFS, imponi build cumulative sui check-in (per assicurarti che tutti gli altri sappiano immediatamente se il loro check-in interrompe qualcosa) e puoi configurare il server per eseguire un check-in gated ( se il codice archiviato interrompe la compilazione, il server lo rifiuta), oppure puoi semplicemente farlo creare un bug e assegnarlo a chiunque abbia interrotto la compilazione.

Ci sono alcune altre opzioni che puoi attivare o disattivare per mantenere tutto in ordine, o suggerire al tuo amministratore TFS di attivare per mantenere le cose belle e pulite ... ma sono in gran parte delle preferenze

7
guildsbounty

Se esegui il check-in da Windows, controlla se il tuo codice non ha quei caratteri ^ M invisibili - gli editor in UNIX spesso danno errori/avvisi a causa di ciò.

Prova anche a sostituire le schede: diversi utenti finiranno per vedere le schede in modo diverso alcune con 4 spazi, altre 8 e non buone per la leggibilità del codice.

Il miglior approccio IMHO è fare in modo che uno script predefinito verifichi il codice in base alle linee guida di codifica della propria organizzazione. Un sacco di sistemi di controllo del codice sorgente ha questa funzionalità.

4
Fanatic23

Nella mia azienda utilizziamo le recensioni per il check-in. Questi non devono essere dettagliati, ma solo mostrare a qualcuno le differenze nella tua lista dei cambiamenti e parlare attraverso di loro a volte evidenzierà lo strano errore che hai perso nei test.

Il nostro server di controllo del codice sorgente non ti consentirà di effettuare il check-in se non annoti il ​​nome del revisore nei commenti (nel modulo! Iniziali, ad esempio! BW se Bruce Wayne ha fatto la tua recensione). Il revisore riceve un'email in cui rileva che ha contribuito alla revisione. Questo è aperto allo sfruttamento ovvio ma sembra funzionare abbastanza bene.

4
tenpn

Quando possibile, mi piace associare un check-in a un oggetto di lavoro. Questo ti dà alcune informazioni contestuali su PERCHÉ questo è stato cambiato, non solo COSA è stato cambiato. TFS ha un sistema di tracciamento degli oggetti di lavoro abbastanza decente, quindi è piuttosto banale da fare al momento del check-in.

(questo è in aggiunta alla revisione delle differenze delle mie modifiche)

4
mpeterson

Una piccola cosa che faccio è non fare il check-in dei file che non sono realmente cambiati. Questi file potrebbero essere stati modificati inavvertitamente, oppure potrebbero essere stati coinvolti in refactoring che sono stati sottoposti a rollback o che sono stati altrimenti sottoposti a moot.

In questo modo, il changeset (associato a un elemento di lavoro) contiene esattamente i file necessari per soddisfare l'elemento di lavoro.

3
John Saunders

Per combinare tutte le risposte qui e dare una lista di controllo completa

  1. [check-in/check-out] non dovresti effettuare il check-in direttamente allo stream su cui stanno lavorando gli altri. Dovresti avere una strategia di streaming: ad es. per sviluppatore un flusso in cui è possibile effettuare il check-in e il check-out in modo indipendente senza disturbare gli altri: il tuo lavoro sarà sicuro ma nel tuo flusso di sviluppo, quindi [solo nel tuo flusso di sviluppo]. Ad ogni check in lo associ a un record di modifica in modo che le tue modifiche siano atomiche rispetto a quella modifica chiamata set di modifiche (in modo da poter distribuire singoli rfc/bug ecc ... senza dover consegnare "tutto").

  2. [quindi rebase con lo stream del tuo team] significa che ricevi le modifiche dagli altri nel tuo stream. Durante tale operazione puoi vedere nella finestra di dialogo di unione tutti i "diff" e analizzarli o ... se ce ne sono migliaia e/o stai usando non un codice ma anche ad es. modelli di dati/progetti siebel ecc ... si basano su fusioni non banali, banali banali-automatiche e banali manuali, l'ultima categoria contiene quelle difficili. Ricorda che stai ancora lavorando nel tuo stream.

  3. [rebase completo] Se tutto va bene, controlla tutte le modifiche che hai appena ricevuto dallo stream del team: il tuo stream è ora aggiornato

  4. [consegna] ora consegna il tuo lavoro allo stream del team. SE non desideri fornire tutto ciò che puoi anche selezionare, ad es. 1 RFC specifico con le versioni specifiche di file o una serie di RFC/difetti risolti.

  5. [test di consegna] dovrebbe andare bene, ma dato che esiste la possibilità che qualcuno nel frattempo abbia consegnato anche delle modifiche: puoi testare se il tuo lavoro funziona con le ultime modifiche nel flusso del team. Con le stesse finestre di dialogo di unione che mostrano le differenze.

  6. [consegna completa] completa la consegna e il tuo lavoro è ora nel flusso del team.

Per renderlo più complesso: poiché esiste ancora la possibilità che il lavoro che hai consegnato = ok MA stai già lavorando su un'altra versione, devi basare sempre dopo la consegna e indicare quale baseline è quella preferita per gli altri utenti . Ciò garantisce che altri sviluppatori ne ottengano una consigliata e non l'ultima versione sullo stream (se si lavora in quello scenario). Questo è anche un triplo controllo in modo che anche se le ultime versioni nello stream del team sono "cattive", non sono ancora quelle a cui gli altri si rifanno o guardano e il tuo gestore della configurazione può unire la versione precedente alla versione successiva per annullare la tua consegna.

  • la risposta dall'istume avviene 2 volte: nei passaggi 2 e 6
  • la risposta di Oded al check-in dance: idem ma un ulteriore livello di consegna e rebase al check-in/check-out per assicurarsi di lavorare in modo isolato e gli errori possono sempre essere facilmente eliminati anche nelle fasi successive
  • la risposta dalla risposta alla gilda: ottenere le ultime è il passaggio 2. Per la build: dipende davvero se HAI una build ... nel mio mondo hai input da modelli di dati, documenti Word, fogli di requisiti, dati di configurazione da informatica, siebel, ecc., e sì anche Java, codice .net ecc ... che tutti dovrebbero mescolarsi insieme. Quindi non c'è davvero "una build" qui ma più un'integrazione più in alto a seconda che quella singola build del tuo "codice", ad esempio, si integra con tutto il resto, poiché non puoi sapere con certezza se si tratta di elementi di integrazione e, a seconda del loro ambiente di test, potrebbero essere necessari elementi compilati o, a consegne più elevate, un altro build perché ha bisogno di qualcosa da un'altra squadra.
  • la risposta della gilda su commenti e richieste: penso che ogni ambiente in cui non si ha l'integrazione di VERSIONI e Modifiche nei set di modifiche (e tipo: difetti, RFC, hotfi) non sia maturo. Penso che sia il caos se non puoi ad es. automatizzare le note di rilascio con la quantità di bug e rfcs inviati che sono cliccabili fino alle esatte versioni toccate (dal momento che ad esempio la versione 1 e la versione 3 di hello.c potrebbero benissimo essere consegnate ma la versione 2 non avrebbe dovuto essere consegnata perché quella roba dentro ci sarebbe parte di una versione successiva ma alcuni noob l'hanno già inserito) (quindi significa una decisione manuale SE vuoi anche eliminare la versione 3 di ciao.c MA togliere la versione 3 significa che devi anche eliminare tutto altra versione toccata da quel RFC/difetto, quindi devi essere in grado facilmente e velocemente con uno strumento per estrarre il tutto) (anche se più sviluppatori hanno lavorato su parti dello stesso RFC) ma almeno hai bisogno di roba attorno per decidere su di esso ecc ...). La documentazione aggiuntiva è sempre utile ma associando i set di modifiche si ottiene il cerchio completo: una versione <- un set di modifiche <- elementi di lavoro <- un ticket/rfc/difetto <- un requisito. Significato: sapete quali requisiti sono interamente o completamente forniti: un requisito ha più RFC o bug o altro. RFC ha più oggetti di lavoro per più persone. quell'elemento di lavoro corrisponde a una serie di modifiche che esiste di una serie di versioni (ad esempio le versioni 1 e 3 di hello.c sul flusso di integrazione che NON sono ovviamente NON le versioni 1,2,3,4,5 nel flusso di sviluppo di quella versione 3 nel flusso di integrazione corrisponde a) (quindi un albero delle versioni e strumenti per operare su di esso)
  • il commento di luis.espinal: non interrompere la build è ricontrollato in rebase e consegnare ancora ... ci sono consegne più alte per "gestori delle versioni e build meister" che dovrebbero vedere i set di modifiche e le linee di base come le loro informazioni. "Non lavorare mai direttamente sul ramo principale" sì, la struttura del flusso può essere grande o semplice ma in sostanza: gli sviluppatori hanno il loro flusso, consegnano a un flusso di squadra che consegna a un flusso di rilascio. -> in modo che le consegne di tutti i team (ad es. team di documentazione, team di requisiti, team di sviluppo, team di test) siano presenti nei loro flussi di team e un gestore delle versioni o il responsabile della configurazione acquisisca le linee di base che dovrebbero andare in una versione e quindi documentazione corretta con le versioni di test corrette documenti/risultati con i requisiti corretti con le versioni di codice corrette sono tutti in linea per una versione.

Nel tuo esempio dai che hai dimenticato di commentare il codice. Gli errori accadono. Il sistema di gestione della configurazione che lo circonda dovrebbe occuparsene. Può davvero essere quello, ad es. arrivano migliaia di modifiche e "build" e "integrazioni" avvengono in una gerarchia di flussi su server diversi concatenati ed elaborati nel tempo. Quindi, anche se dopo 5 mesi il tuo codice commentato viene testato su un server di integrazione perché il tuo codice necessita di integrazione con altri codici e sistemi, dovrebbe comunque essere possibile eliminare atomicamente il tuo set di modifiche e continuare. Quindi la migliore pratica è più o meno ad un livello superiore. La progettazione generale dei flussi di gestione della configurazione dovrebbe occuparsene. Per i singoli sviluppatori è buona prassi naturalmente convalidare/unit test. Ma dal quadro generale per "farlo funzionare", la migliore pratica è seguire il sistema e fornire sempre quelle meta informazioni relative ai set di modifiche per i ragazzi più avanti nella catena.

3
edelwater

Alcuni dei seguenti si applicano più di altri (o in forme diverse) a seconda del tuo SCM, quindi eccoli qui:

  1. Non interrompere la compilazione: controlla solo il codice che viene compilato.
  2. Commenta i tuoi check-in (e possibilmente i tuoi check-out se SCM ti offre questa opzione).
  3. Non tenere le cose deselezionate per lunghi periodi di tempo.
  4. Effettua il check-in spesso (se possibile più volte al giorno).
  5. Etichetta in modo significativo.
  6. Etichetta regolarmente.
  7. Non lavorare mai direttamente sul ramo principale.
  8. Ogni rilascio alla produzione deve avere una propria etichetta (e un ramo di sola lettura al largo del ramo principale, se possibile). Se possibile, fare lo stesso per le versioni di test UAT/Integration/Pre-production.
  9. Dovresti essere in grado di costruire esattamente ciò che è in produzione da ciò che è nel tuo SCM e da un'etichetta.

NOTE : alcuni degli articoli sopra sembrano piuttosto ovvi, ma non crederesti quante persone lavorano effettivamente nel ramo principale o apportano prima delle modifiche alla produzione - e quindi crea manualmente delta per passare al controllo versione ... direttamente sul ramo principale ... e con le etichette. Dolce come la bile fermentata mescolata con succo di ascella non lavato ... sì, così.

2
luis.espinal

Avere una lista di controllo personale. Avvialo vuoto quando sbagli, a una voce. Quando diventa una seconda natura rimuoverlo dall'elenco.

Esegui i test. Se passano, controllalo. Se sbagli e qualcosa supera i test, scrivi un test.

2
ctrl-alt-delor

Sempre, sempre, sempre, verifica che qualsiasi modifica apportata non interrompa la creazione. Soprattutto piccoli cambiamenti che possono sembrare banali.

Una volta ho apportato una modifica molto piccola che non pensavo potesse causare problemi prima di lasciare il lavoro per il fine settimana. Abbastanza sicuro, quel piccolo cambiamento ha rotto la costruzione e non sono state eseguite prove notturne per il nostro progetto. Il capo delle domande e risposte non era molto contento di ciò, e giustamente.

1
gablin

Esegui i test unitari su cui hai lavorato così diligentemente. Il verde è buono.

1
Naftuli Kay

Assicurati che il tuo codice sia formattato correttamente (ad es. Per Java: seleziona il tuo codice e premi Ctrl-Shift-F in Eclipse). Fai attenzione a fare lo stesso per un intero documento.

1
Rune Aamodt

Facciamo il seguente ...

  1. Test: vogliamo assicurarci che funzioni. Per lo meno, vogliamo sapere che non rompe nulla.

  2. Revisione del codice, o almeno un controllo del compagno - Questo è un ottimo modo per garantire che le conoscenze vengano diffuse e che le persone siano tenute aggiornate. Aiuta anche a catturare i bug prima di fare il check-in.

  3. Invia un preavviso: un avviso anticipato viene inviato al gruppo prima del check-in. Lo scopo non è solo quello di far sapere agli altri quali file o aree stanno cambiando, ma dà loro un avvertimento (se dovessero scegliere di prenderne atto) nel caso in cui si prevede che tali cambiamenti li influenzeranno.

  4. Alcune ore dopo l'invio dell'avviso, viene eseguito il check-in e il gruppo viene informato via e-mail. Tutti nel gruppo possono sapere quando viene eseguito il lavoro specifico su un bug o una funzione.

  5. Una copia dell'avviso di check-in viene incollata nel record di correzione associato al bug o alla funzione. Durante la ricerca tra i record, scopriamo che è molto utile avere un'idea di cosa comportava la correzione/funzionalità.

1
Sparky

Cerca parti delle modifiche che possono essere inserite come unità autonome.

Spesso, quando ho una correzione funzionante o un miglioramento del codice, ci sono alcune modifiche. Alcuni di loro sono specifici per il cambiamento di comportamento che sto cercando; altri sono refactoring che ho fatto per rendere più pulito quel cambiamento.

Preferisco controllare ciascun refactoring separatamente, con la sua descrizione del cambiamento, in questo modo:

REFATTORAZIONE: Rinomina da X a Y

X aveva senso prima perché ... ma ora dovrebbe essere Y. Questo è legato al lavoro per il numero 9.

Quindi, una volta verificato ogni buon refactoring, il cambiamento di comportamento finale è spesso banale.

Inoltre, alcune modifiche influiscono su molte righe di codice ma non sono molto interessanti, mentre altre sono molto localizzate ma hanno un impatto importante. Se queste modifiche vengono registrate insieme, può essere difficile leggere le differenze. Quindi, li tengo separati.

Più tardi, quando qualcuno sta leggendo la storia del cambiamento, è ovvio come le cose sono arrivate allo stato attuale delle cose e perché sono così. È anche banale annullare il mio cambiamento di comportamento perché non è aggrovigliato con tonnellate di altre modifiche.

1
Jay Bazuzi

Tengo un repository hg locale per il mio lavoro.

  • Ogni volta che eseguo il check in, guardo il diff e mi assicuro che tutte le modifiche siano accettabili.
  • Provo a notare la caratteristica chiave del check-in.
  • Cerco di mantenere ogni dimensione di commit su una caratteristica chiave.

Non pretendo che questi siano i migliori, ma funzionano per me.

0
Paul Nathan

Fai quello che faresti quando restituisci qualcosa che hai preso in prestito da qualcuno. Assicurati che sia pulito e in buona forma. Se hai fatto un casino, assicurati di pulire prima di restituire il codice al suo proprietario (nella maggior parte dei casi, il tuo datore di lavoro).

0
Jason

Quando scrivo un codice che so non è destinato al check-in, aggiungo una riga prima che contenga "// TEMP:" e dopo con "// END TEMP.". Questo, insieme a fare diff prima del check-in, promette che non controllerò quel codice per errore.

0
user17815

Testa a fondo tutto ciò che hai aggiunto o modificato. Prova ogni possibile caso che ti viene in mente di provare. Non lasciare i test al QA. Se avessi un sandwich per ogni volta che ho apportato alcune piccole modifiche, e poi ho provato alcuni casi di test solo per essere al sicuro, e ho subito visto i problemi, avrei molti sandwich. Di solito mi dico ad alta voce "Sono davvero felice di aver provato ..."

Dici che l'interfaccia utente è diventata strana dopo la modifica. Se avessi solo eseguito il programma e guardato l'interfaccia utente prima del check-in, avresti notato il problema?

0
Ken