Le migliori abitudini di controllo della versione per sviluppatori singoli?


36

Sono uno sviluppatore unico nel mio lavoro e mentre comprendo i vantaggi di VCS; Trovo difficile attenersi alle buone pratiche. Al momento sto usando git per sviluppare principalmente app web (che non saranno mai open source a causa del mio lavoro).

Il mio attuale flusso di lavoro è apportare molte modifiche al sito di sviluppo, testare, revisionare, testare, essere contento e confermare le modifiche, quindi spingere il commit sul sito live (quindi se sto lavorando su una grande novità, potrei solo commettere una volta alla settimana; ma il mio IDE ha una buona cronologia degli annullamenti per le cose non impegnate).

Fondamentalmente, sto usando git solo quando si passa da una macchina all'altra (ad es. Dal computer di sviluppo del lavoro al computer di casa o alla macchina live), ma durante il giorno non vedo davvero il vantaggio. Questo mi porta ad avere lunghi elenchi di modifiche (e ho difficoltà a trovare un buon messaggio per ogni commit; e ogni volta che ho fretta - tendo a lasciare messaggi scadenti come "modifiche varie ad admin e template").

Quanto spesso dovrei impegnarmi? Ogni modifica di una riga dovrebbe ricevere un commit? Devo impegnarmi prima di qualsiasi test (ad esempio, almeno per errori di sintassi / compilazione e quindi doverlo annullare completamente; poiché l'idea non ha funzionato o il messaggio è una bugia)?

Devo assicurarmi di impegnarmi ogni mattina / pomeriggio prima di smettere di lavorare per cena mentre è ancora fresco? Cosa mi sto perdendo avendo cattive abitudini VCS?


2
Forse uno dei tuoi problemi per cui ritieni che VCS non funzioni per te è perché stai usando Git come sviluppatore solista? Git mi sembra eccessivo per un singolo sviluppatore, forse qualcosa di più semplice con meno funzionalità come SVN sarà più facile da usare?
maple_shaft

6
@maple_shaft: non ho usato Git, ma Mercurial è semplice quanto Subversion per le attività di base per gli sviluppatori da solista. (Più semplice, in realtà, poiché creare l'equivalente del repository è più facile.)
David Thornley,

15
Perché Git sarebbe eccessivo?
Tamás Szelei,

1
@maple_shaft il vero vantaggio arriva dopo. Non c'è bisogno di accontentarsi di meno.

3
Vale la pena ricordare che per DVCS come git e mercurial, per sfruttare i vantaggi di un backup fuori sede del controllo del codice sorgente (come menzionato in alcune delle risposte) dovresti spingere regolarmente, non solo impegnarti.
rimorchiatori

Risposte:


24

Ti stai perdendo molto.

Sono anche solo, in un certo senso. Mi impegno ogni volta a fare un cambiamento significativo, o prima di avviarne uno significativo in modo da poter tornare indietro se rovino le cose, e ogni tanto anche se non sto facendo nulla di grande. Davvero non tutti i giorni, ma vicino. A volte poche volte al giorno.

Quello che ottengo è che posso tornare indietro ogni volta che voglio. Che è molto. Inoltre, avere i rami ordinati aiuta.

Immagino che mi dia molto ordine.

Sto usando svn e mi sto stancando. Ma non posso passare più tempo ad imparare altro.

In bocca al lupo.


+1 Ho recentemente iniziato a utilizzare VCS da solo, e GIT è la cosa giusta per me :)
yati sagade

1
Avevo evitato il controllo della versione per molto tempo perché avevo l'impressione che fosse troppo ingombrante / brutto / fastidioso. Qualche mese fa ho deciso di familiarizzare con Subversion e ora lo giuro.
Dalin Seivewright,

1
Ho diversi progetti da solista: alcuni su Github, altri no. Uso sempre git anche se sto solo costruendo qualcosa per gli scopi espliciti di apprendere un particolare API / strumento. Fa rispettare le buone abitudini per i progetti reali in cui è più utile, come descrive @jbcolmenares.
Sarumont,

2
Contatterò il tuo "non posso passare più tempo a imparare altro" con hginit.com . Conta il tempo che passi ad arrabbiarti con svn per una settimana, quindi prendi quel tempo per leggere hginit la settimana successiva.
martedì 18

@tdammers darà un'occhiata
cauchy

18

Dovresti impegnarti spesso. Dovresti certamente impegnarti dopo aver raggiunto un traguardo logico. Se ciò richiede più di un giorno, dovresti almeno impegnarti alla fine della tua giornata di lavoro, o meglio ancora, suddividere il tuo lavoro in blocchi più piccoli.

Ci sono molte ragioni per farlo. Ad esempio, cosa succede se il computer si arresta in modo anomalo? È molto meglio perdere solo un giorno di lavoro rispetto a una settimana o un mese. Un altro motivo è che frequenti commit rendono più semplice isolare un bug. Puoi fare una ricerca binaria e capire quale piccola modifica ha causato il bug.

Un'altra cosa: prima di impegnarti, dovresti fare una diff e guardare tutte le modifiche che hai apportato. Ciò ti consente di verificare che tutte le modifiche abbiano un senso e che non hai dimenticato nulla. Questo ti aiuta anche a trovare un messaggio di commit migliore. E, naturalmente, questo è un altro motivo per impegnarsi spesso: è molto più facile passare attraverso un giorno di modifiche rispetto a un mese.


"Cosa succede se il computer si arresta in modo anomalo": i file vengono salvati su disco abbastanza frequentemente e i backup vengono eseguiti di notte (se intendevi se il disco rigido si rompe). Tuttavia, +1 per la ricerca binaria di bug potrebbe tornare utile. Sono abbastanza bravo a trovare rapidamente il 95% dei miei bug; ma ogni tanto c'è un bug davvero bizzarro derivante da un cambiamento apparentemente insignificante in un'altra parte del programma.
dr jimbob,

Sì, intendo "se il disco si rompe", "se il soffitto cade" o "se un dispositivo EMP si spegne nelle vicinanze". :) Tutto ciò che può causare una perdita di dati. Il commit spesso è il modo più semplice per eseguire il backup del lavoro e consente di eseguire facilmente un backup fuori sede, utilizzando un server di controllo versione remoto.
Dima,

1
@Dima: dovrai spingere e non solo impegnarti ad avere il tuo backup
liberforce

@liberforce Non tutti i sistemi di controllo della versione hanno operazioni push. Questa risposta è del 2012. Stavo usando sovversione al momento, che non è distribuito. Quindi, nessuna spinta.
Dima,

2
@Dima: certo, ma l'OP stava usando git, quindi le istruzioni potrebbero essere fuorvianti poiché non hai detto che stavi parlando di SVN.
liberforce

10

Per ottenere il massimo da CVS dovresti lavorare su una funzione / correzione di bug alla volta e impegnarti quando quella funzione / correzione di bug è completa. In questo modo otterrai:

  • i messaggi di commit saranno più facili da creare e avranno più senso;
  • più facile rintracciare i bug futuri alle modifiche che li hanno introdotti;
  • tornare più facilmente a uno stato precedente (anche se ciò significa perdere una funzionalità non riuscita ma mantenere correzioni di errori che si sono verificate in seguito).

Inoltre, poiché passi da un PC all'altro dovresti avere almeno due rami:

  • un ramo "Pronto all'uso" che funziona sempre (tranne i bug a cui stai lavorando nel ramo di sviluppo, ovviamente)
  • un ramo di sviluppo che di tanto in tanto può essere in uno stato incontrollabile (come durante il viaggio di ritorno dal lavoro;).

1
+1 per il ramo pronto all'uso! Non so quante volte mi viene chiesto di mostrare il software mentre passano il capo e i potenziali clienti. È bello avere una versione che funziona davvero e non in uno stato di flusso.
bluebill

Una versione che funziona e viene testata solitamente è taggata. Questo è ciò che dovresti mostrare, a meno che il capo non voglia vedere le ultime modifiche. In tal caso, devi solo git stashmostrare ciò che hai o verificare un commit specifico. Naturalmente, se si hanno grandi cambiamenti che sono un work in progress, questi dovrebbero trovarsi in un ramo work-in-progress separato, quindi il ramo master è di fatto stabile.
liberforce

7

Ogni modifica di una riga dovrebbe ricevere un commit?

Se questo è ciò che risolve un bug, certo.

Cosa mi sto perdendo avendo cattive abitudini VCS?

Ho lavorato con un ragazzo che aveva "cattive abitudini VCS". Amava lavorare tutto da solo ed era responsabile di una linea di prodotti che portava a qualcosa come 1.000.000 di dollari all'anno. Commetteva solo quando il capo lo tormentava. Poi un giorno il suo disco rigido si è schiantato. Dopo aver ricevuto una configurazione sostitutiva per lui, abbiamo scoperto che il suo ultimo check-in era stato 6 mesi prima. Dato che VCS era sicuro per la fonte, puoi indovinare cos'altro è andato storto: l'ultimo commit è stato danneggiato. Abbiamo dovuto tornare più di un anno per ottenere una versione non corrotta della sua linea di prodotti. Non è stato licenziato, anche se avrebbe dovuto essere.

Un altro aneddoto coinvolge me stesso. Conservavo il codice per hobby e progetti di ricerca su hard disk rimovibili. Un giorno, il mio appartamento è stato fatto a pezzi. Il laptop (che era rotto) e tutti i dischi rigidi rimovibili sono stati rubati. Ogni DVD (ad eccezione di Red Dawn) è stato rubato. Nessuno dei computer desktop è stato rubato. Se avessi avuto il controllo della fonte fuori sede, non avrei perso 15 anni di progetti, soprattutto perché alcuni erano basati su progetti accademici - molti dei professori hanno lasciato il mondo accademico per andare nel settore privato, quindi quei progetti sono svaniti in un buco nero IP aziendale rendendo il codice perso impossibile da recuperare.

Quanto spesso dovrei impegnarmi?

Lo scompongo in alcune metriche:

  • Quanto lavoro sei disposto a perdere se il tuo computer muore? o viene rubato?

  • Se questo risolve Bug_1234, controlla il codice con il commento "correzioni Bug_1234".

  • Se si tratta di una consegna logica / pietra miliare, esegui il check-in con un commento come "Bug_1234, form_xyz" (o Task_1234, a seconda dei casi).

  • Controlla sempre il codice il venerdì sera prima di tornare a casa. Effettua anche il check-in (o annulla i checkout) di tutto prima di partire per le vacanze.

  • Ogni volta che la politica aziendale lo richiede.


1
Sono d'accordo che il ragazzo avrebbe dovuto essere licenziato. Non commettere, anche per quanto riguarda le uscite, è una follia. Come puoi trovare i bug che sono apparsi nella versione 1.2 se non sai quale codice è nella 1.2? Il ragazzo stava solo copiando il codice e zippando sul suo disco rigido?
liberforce

5

Non pensare in termini di modifiche al numero di righe. Pensa a pezzi di funzionalità. VCS ti consente di indicare un'intestazione in una posizione centrale per ogni blocco di funzionalità in modo da poter vedere facilmente "cosa è successo qui" con ad esempio git log.

Inoltre, IDE come Eclipse ti consente di puntare a una determinata linea e andare al commit che lo ha portato nella forma che vedi. In altre parole, puoi passare direttamente da una linea di origine al commit. Se il commit è di piccole dimensioni e ha un buon messaggio, è molto più utile di "risolti tonnellate di bug".


4

Direi che la cosa più grande a cui ti stai perdendo raggruppando le modifiche in questo modo è la capacità di rintracciare quando e dove sono stati introdotti i bug.

Nella mia esperienza, ci sono state un paio di volte in cui si è notato qualche insetto due-tre settimane dopo che è stato introdotto e dover passare in rassegna il valore di una settimana di commit è difficile tanto tempo dopo il fatto. In questi casi, è stato utile semplicemente eseguire una ricerca binaria attraverso gli commit per rintracciare quali cambiamenti individuali hanno causato il problema. Questi bug erano principalmente errori di utilizzo della memoria sul codice C ++, quindi potrebbe non accadere così spesso per il tuo progetto.

Altri vantaggi entrano in gioco quando si sviluppa in una squadra: semplici commenti di commit, fusioni più facili, impegni relativi a correzioni di bug, ecc.

Immagino con il tuo flusso di lavoro che se inizi a impegnarti quotidianamente o semi-giornalmente, dovrai usare tag o segnalibri per tenere traccia di quale versione del codice è in uso sul sito live. Direi che è la cosa più importante di cui tenere traccia.


4

Anch'io sono uno sviluppatore solista, utilizzo SVN e lo adoro. Ho persino scritto uno strumento per convertire la struttura del mio database e i dati del test in esso in XML in modo da poterlo includere nel controllo del codice sorgente.

Di solito mi impegno ogni volta che ho completato un'unità di lavoro autonoma. A volte, se eseguo un mucchio di correzioni a linea singola banali e non correlate qua e là, le commetto tutte insieme, ma se succede una correzione a linea singola tra due grandi unità di lavoro autonome non correlate, allora ottiene la sua commettere, non c'è niente di sbagliato in questo.

Inoltre, commetto sempre codice che viene compilato e quasi sempre codice che supera anche tutti i test di base. In caso contrario, mi assicuro di includere "NON FUNZIONA" nel messaggio di commit. L'unico caso in cui ciò accade è quando ho fatto cambiamenti importanti che non voglio perdere anche se non funzionano ancora del tutto, e per di più sto per intraprendere una grande avventura di refactoring che non sono sicuro se avrà successo. Quindi, quindi, uso il repository come backup del lavoro che ho svolto finora prima di rischiare di rovinarlo e buttarlo via.

Ciò significa che mi impegno sempre quando è necessario eseguire il commit del mio codice sorgente; non ha assolutamente senso avere regole di impegno mattutino o serale. È lo stato in cui si trova il codice a decidere se è il momento di impegnarsi o meno.

I messaggi che hai inserito nel repository non contano molto. Se non riesci assolutamente a trovare qualcosa di significativo, è ancora meglio impegnarsi con un messaggio vuoto piuttosto che non impegnarsi affatto quando dovresti.

Se non riesci a pensare a un buon messaggio di commit perché tutto quello che ti viene in mente sembra stupido, tieni presente che va bene; ci si aspetta che i messaggi di commit dichiarino l'ovvio, quindi sono destinati a sembrare stupidi quando li scrivi. Ma fidati di me, se hai bisogno di esaminare vecchie revisioni un mese dopo sarai grato anche per gli stupidi messaggi su nessun messaggio.


1

Commettere ogni volta che si esegue una modifica "logica". Ad esempio, se stai implementando una nuova funzionalità, la stai facendo passo dopo passo. Ognuno di questi passaggi di solito dipende l'uno dall'altro. Quindi puoi semplicemente eseguire il commit di questi passaggi separatamente e spiegare nel messaggio di commit perché ogni passaggio è necessario.

Il messaggio di commit è davvero importante. Devi evitare di dire cosa stai facendo, dire perché lo stai facendo. Il codice documenta già le modifiche, ma in 6 mesi sarai felice di capire perché le hai apportate.

Questo è utile anche se per caso qualcuno salta dentro e non sei più solo. Anche solo per te, una cronologia chiara semplifica l'uso di a git blameper sapere quando e perché è stata modificata quella riga che presenta un bug.

Effettuare piccoli commit invece di grandi cambi di palla di fango consente anche di testare lo stato intermedio. Puoi nascondere le modifiche se devi rilasciare qualcosa con urgenza. Se si introduce un bug mentre ha funzionato in precedenza, è possibile archiviare e verificare se sono le modifiche senza commit che introducono il bug o se era presente in un commit precedente.

Puoi anche liberare il potere di git bissectciò che ti dirà l'impegno che questo brutto bug. Se il commit è lungo 2.000 righe, aiuta ancora ma non molto ...

Un'altra cosa è che è il primo passo per l'integrazione continua (CI) e quindi la distribuzione continua (CD). CI e i tuoi test possono essere attivati ​​su un nuovo commit, quindi ti dicono ogni volta che spingi le modifiche se interrompono qualcosa o no. In questo modo puoi sapere se è sicuro implementarlo o meno e riceverne una notifica al momento in cui il problema viene introdotto e non appena prima della tua uscita quando sei di fretta.

Informazioni sulle altre tue domande:

  • non commettere cose che non hai nemmeno compilato, a meno che tu non sia disposto a riscrivere la tua storia per questo (usando git rebase --interactive).
  • una modifica di una riga merita un commit se ha uno scopo separato (corregge un bug o non è correlata alle modifiche attualmente non impegnate). Usa git add --patchper mettere in scena quelli.
  • non c'è bisogno di forzarti a impegnarti prima di cena, a meno che tu non abbia cose importanti che non puoi permetterti di perdere. In tal caso, potresti voler impegnare in un ramo separato i tuoi lavori in corso.
  • il commit e il push in un repository remoto è un backup. Se ti impegni e spingi solo una volta alla settimana, nel peggiore dei casi puoi perdere una settimana di lavoro.

0

Quanto spesso dovrei impegnarmi?

Come sviluppatore solista mi impegno generalmente ogni volta che sento di aver apportato un cambiamento significativo, dopo i test di base e quando lascio un progetto alla fine della notte.

Ogni modifica di una riga dovrebbe ricevere un commit?

No, a meno che la modifica di una riga non cambierà significativamente una funzionalità o un bug.

Devo impegnarmi prima di qualsiasi test (ad esempio, almeno per errori di sintassi / compilazione e quindi doverlo annullare completamente; poiché l'idea non ha funzionato o il messaggio è una bugia)?

Probabilmente no. Almeno per me faccio la maggior parte dei miei test e codifica su una "copia di lavoro" e mi impegno dopo che sono soddisfatto delle mie modifiche. In molti IDE, questo mi mostrerà cosa è cambiato prima di effettuare effettivamente il commit e mi darà l'opportunità di allegare note al commit

Devo assicurarmi di impegnarmi ogni mattina / pomeriggio prima di smettere di lavorare per cena mentre è ancora fresco? Cosa mi sto perdendo avendo cattive abitudini VCS?

Non ho molta familiarità con VCS o quali cattive abitudini provoca. Penso di aver maggiormente condiviso la mia opinione su questo in risposta alla prima domanda.

In risposta alla domanda generale postulata, sembra che tu stia utilizzando principalmente i commit come branch che sono indirizzati in un altro post di responder. Non sono sicuro di quale IDE stai utilizzando che abbia una buona cronologia degli annullamenti, ecc., Ma non ne ho trovato uno che mi è sembrato buono al di là del riavvio dell'IDE e dello spostamento tra le macchine.


I am not very familiar with VCS or what bad habits it causes.Sei fortunato!
yannis,

1
Non sono sicuro di come l'ho letto erroneamente più volte, ma ho continuato a leggerlo come 'VSS' come in Visual source sicuro. Ho una certa familiarità con alcuni diversi sistemi di controllo della versione tra cui SVN e GIT e li uso frequentemente come sviluppatore solista, ma probabilmente ho alcune cattive abitudini me stesso considerando che non li ho davvero utilizzati nel contesto di un ampio scenario multi-sviluppatore .
Dbuell,

Bene, dato che ho combattuto con SourceSafe per più di 3 anni, il mio commento è ancora valido: Lucky you! Per fare un esempio, VSS6 potrebbe gestire repository di circa 200mb - 300mb, dopodiché se si fosse fortunati alcuni file verrebbero danneggiati in modo casuale. Ovviamente lì dove più correzioni, soluzioni alternative e VSS non sono mai state pensate da MS come un vcs completo, ma consideri fortunato che non hai mai dovuto affrontarlo ...
yannis,

0

Sono un committer abituale e ho scoperto che mi andava bene, ma è vero che i miei messaggi di commit sono quasi sempre come,

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Quindi non posso dire con esattezza che effettuare commit così frequenti e abituali nella mia filiale (mercuriale) abbia incoraggiato esattamente i log di commit più dettagliati. A volte commetto anche il codice a metà, se, per esempio, mia moglie mi chiede di uscire a cena, a quel punto copierò in fretta e userò il precedente messaggio "Lavorando su [...]".

I miei modelli di log di commit sono in genere come, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Il rovescio della medaglia però, mi ha salvato il culo. A volte mi imbatto in un caso limite che non avevo previsto e testato contro, a quel punto i frequenti commit mi aiutano a capire esattamente dove ho introdotto l'errore.

Quindi non conosco le migliori abitudini e non sono certo uno che ascolta per quanto riguarda le abitudini ideali di registrazione dei commit, ma posso sicuramente dire che impegnarsi più frequentemente può sicuramente aiutare quando è necessario eseguire una regressione.

Ogni modifica di una riga dovrebbe ricevere un commit?

Ho già apportato modifiche di una riga prima, ma di solito complicate e forse avevo poco tempo. I miei impegni non assomigliano sempre a unità di lavoro o cambiamenti perfetti e completi. Come detto, a volte sono solo il risultato di mia moglie che mi chiede di uscire a cena inaspettatamente.

Molti dei miei impegni di TBH che seguono quel "Working on [...]"modello di registro non modellano unità coerenti di cambiamento (perché spesso non riesco a trovare un messaggio migliore di "Working on [...]") ma solo il risultato di una pausa, come farmi una tazza di caffè. Il "Completed [...]"messaggio indica la fine di quell'unità di lavoro, e lì scrivo spesso un messaggio molto più dettagliato insieme ai messaggi di primo "Started working on [...]"tipo quando inizio a lavorare su qualcosa. Se in media commetti come una volta ogni 15 minuti, quei messaggi "Lavorando su [...]" sono più simili a quelli intermedi per ciò che qualcuno potrebbe commettere in un commit più voluminoso con un messaggio più dettagliato.

Devo impegnarmi prima di qualsiasi test (ad esempio, almeno per errori di sintassi / compilazione e quindi doverlo annullare completamente; poiché l'idea non ha funzionato o il messaggio è una bugia)?

Vado avanti e lo commetto anche prima di eseguire i test a volte (di nuovo se ho avuto un evento inaspettato). Anche se sono solo, invio a un server (solo uno in esecuzione qui a casa su una LAN) che esegue CI. Potrebbe sembrare eccessivo ma non so, mi sono abituato così tanto a appoggiarlo nei miei precedenti posti di lavoro. Inoltre, non voglio preoccuparmi di dover eseguire manualmente tutte le mie unità e i test di integrazione. Mi piace avere tutto legato solo alla spinta. Se un test fallisce è abbastanza facile lavorare in un modo che procede in avanti dove faccio la regressione, correggere l'errore nell'ultimo giro e andare avanti. Detto questo, almeno costruisco il codice contro una build di debug prima di impegnarmi.

Devo assicurarmi di impegnarmi ogni mattina / pomeriggio prima di smettere di lavorare per cena mentre è ancora fresco?

Mi piace impegnarmi prima di uscire e fare una pausa tra la programmazione. Non ho riflettuto molto sul perché esattamente fino a quando ho incontrato questa domanda. Suppongo sia per impedire a me stesso di riprendere da dove avevo interrotto senza un registro di commit lì al posto di dove avevo interrotto che posso diff e così via. Hmm, ho bisogno di ricontattarti dal momento che forse non è teoricamente necessario data la frequenza con cui mi impegno. Mi sento ancora più a mio agio a impegnarmi e spingere prima di lasciare il computer per qualsiasi motivo. In parte potrebbe essere quella precedente paura psicologica di, diciamo, il computer prende fuoco dopo che me ne vado e avendo i project manager nei giorni in cui stavamo usando SVN con gli sviluppatori a volte andando per settimane senza impegnarci a respirare giù per il collo e ricordarci costantemente di controllare il codice il più spesso possibile ricordandoci che il nostro codice è di proprietà dell'azienda. Inoltre è un po 'più efficiente soprattutto con la spinta in modo che il mio processo di CI possa iniziare a eseguire tutti i test mentre sono via in modo da poter tornare e vedere i risultati.

Oh, a volte mi ubriaco un po 'dopo che me ne vado ed è di solito una cattiva idea provare a scrivere un codice complesso mentre sono ubriaco (anche se non sempre; una volta ho trovato un sistema di menu di scelta rapida davvero piacevole dopo aver avuto un momento eureka mentre ero ubriaco, ma avevo solo 6 birre e non era così complicato da codificare). Se provo a farlo, almeno ho commesso il codice scritto in modo sobrio prima di partire per tornare indietro invece di mescolare il codice ubriaco con il codice sobrio, a quel punto il mio registro di commit potrebbe essere simile, "Reverting back to code written before Jagermeister shots."non lo faccio molto spesso, a meno che non mi sia ispirata al codice dell'ubriaco, ma in quei rari casi, mi ha davvero aiutato a commettere qualcosa prima di uscire e ubriacarmi.


Regola empirica per te: se hai due commit consecutivi con messaggi identici, stai quasi sicuramente sbagliando. O dovrebbero essere un unico commit o dovresti capire cosa c'è di diverso in loro e scrivere messaggi di log che riflettano quella differenza (ad esempio "definisci nuovi dati di disegno" e "imposta correttamente i dati di disegno" anziché "lavorare sul sistema di disegno" x2).
Marnen Laibow-Koser,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.