Quando e come effettuare il commit? [duplicare]

Puoi fare tutto ciò che è socialmente accettabile con i tuoi colleghi programmatori sul progetto a cui stai lavorando. Non ci sono regole in realtà.

Personalmente mi impegno molto spesso a mantenere i set di cambiamenti davvero piccoli e ad assicurarmi che facciano solo una cosa, e quindi possiamo o non possiamo riorganizzare / schiacciare quelli prima di pubblicarli nel team.

Quando ti rendi conto di avere git rebase -i a portata di mano, diventa meno importante la frequenza con cui ti impegni inizialmente.

In termini di commenti, penso che possa essere importante che i tuoi commit siano ben descritti in modo che tu possa gestire le modifiche su cui stai lavorando.

Il controllo del codice sorgente è un po 'personale. In genere, se lavori con un gruppo, avranno le loro procedure relative al momento in cui eseguire il commit e come dovrebbero apparire i tuoi messaggi di commit. In genere ti impegni dopo aver completato qualche compito, non prima. Ricorda che desideri poter accedere al codice più aggiornato possibile in caso di perdita dei dati.

Ecco alcune regole pratiche:

1. Dovresti sempre, al meglio delle tue possibilità, lasciare il codice commesso in uno stato eseguibile. Non inviare nulla se non lo hai testato.
2. Il codice commesso dovrebbe essere il più aggiornato possibile senza violare la regola 1.
3. Dovresti cercare di mantenere i commit il più piccoli possibile. Se risolvi tre bug, è meglio avere tre commit separati (uno per ciascun bug). In questo modo puoi eseguire il rollback di un piccolo cambiamento alla volta. Rende anche più facile trovare dove hai introdotto errori
4. I messaggi di commit dovrebbero essere significativi. Scrivi sempre come se qualcun altro li leggesse (perché non ricorderai cosa hai fatto una settimana dopo il commit)

Ovviamente, a volte (specialmente quando stai iniziando un progetto) è difficile seguire queste regole. O il codice non è abbastanza completo per essere eseguito o le tue modifiche si sovrappongono ed è troppo difficile separarle. Usa il tuo giudizio.

Git è meraviglioso e spaventoso per la sua flessibilità. Sebbene ci siano molti consigli che verranno probabilmente forniti su questo thread, penso che il miglior consiglio che posso dare sia quello di mantenere due rami del tuo codice:

1) master

2) stabile

Mi commetto come un matto sul mio ramo principale. Non c'è alcuna garanzia di alcuna funzionalità su di esso. C'è anche il desiderio di avere una versione del tuo codice che sia stabile ... è qui che entra il ramo stabile. Ogni volta che hai una versione stabile del tuo codice, puoi unire le tue modifiche al ramo stabile.

A seconda di quanto è grande il progetto, potrei avere diversi rami dal master. Ne avrò uno per ogni bit di funzionalità su cui sto lavorando e potrò unire nuovamente le modifiche quando saranno stabili.

Quindi, per farla breve. In git non devi scegliere tra impegnarti spesso e avere commit stabili. Puoi fare entrambe le cose! Mi piace usare gitk o git-extensions per visualizzare i miei rami. Mi aiuta a ricordare dove sono e su cosa sto lavorando per ogni progetto.

Impegnati quando hai completato una "unità di lavoro" coesa. Ciò potrebbe essere la correzione di un errore di battitura in un commento, l'aggiunta di un nuovo modulo a un progetto, l'aggiunta di alcune dichiarazioni di registrazione, la scrittura di un nuovo test unitario e il codice per farlo passare o qualsiasi altra cosa che sia facilmente comprensibile come una modifica discreta a un progetto. La chiave è "facilmente". I commit dovrebbero essere strettamente focalizzati e in grado di essere completamente descritti nel messaggio di commit. Il messaggio di commit è frasi o paragrafi, non libri. In generale, direi che se passi più di un'ora di codifica continua senza commit, stai facendo qualcosa di sbagliato.

Ogni volta che avvio un progetto, creo un elenco puntato dei diversi componenti che devono essere eseguiti e spesso include i sottocomponenti. Non deve essere sulla carta, può essere nella tua mente (anche se la carta è più facile da condividere dei pensieri). Mi impegno sempre quando completo un componente che richiede "qualche sforzo" ed è qualcosa degno di mostrare qualcuno, anche se si tratta di un altro sviluppatore e non di un cliente.

Prima di tutto, come altri, presumo che tu stia lavorando su un ramo locale e che tu abbia un master da qualche altra parte.

Penso che un DVCS ti dia un'enorme quantità di libertà. Cerco di impegnarmi ogni volta che faccio un passo in avanti e il codice viene compilato. Se rinominare una variabile, commetto. Se miglioro un commento, commetto. Il vantaggio di una struttura di commit a grana molto fine è che quando si preme per eseguire il mastering c'è un fascio di commit descrittivi.

I tend to commit, when I fear to hose something. But then the summaries look like "Backup before trying this and that" or just "Backup".

Ancora una volta, un DVCS ti dà la libertà. Non direi "backup prima di provare il condensatore di flusso", direi "condensatore di flusso scritto". Se si scopre che questo non funziona, vorrei sostenere quel particolare cambiamento stabilito. Hai la libertà di farlo perché devi solo preoccuparti che le tue modifiche infrangano altre persone quando ti tolgono o ti spingono al ramo principale.

Puoi prendere consigli pratici da grandi progetti open source di lunga durata, come Chromium, in cui invii prima il codice per la revisione, così puoi discutere presto i tuoi cambiamenti e altri ingegneri possono segnalare i tuoi errori. Quando tutti sono d'accordo che il codice è "abbastanza buono", puoi commetterlo.

Risolve il problema del backup (si dispone di un ramo separato sulla propria macchina e il server di revisione del codice in genere consente di scaricare la patch) e porta a un codice migliore in generale.

La cosa meravigliosa di git è che per la maggior parte è come avere un quaderno di carta, le note in esso non sono condivise e per la maggior parte sono utili (ish) a te solo.

Ciò significa che sei libero di impegnarti su qualsiasi cosa, commetterò cose come "ottimizzato x per 3px", totalmente inutile per gli obiettivi generali di un progetto, ma poi lo rebase in modo che i commit siano chiari e in un bel blocco. Inoltre, con la facilità con cui git rende le diramazioni e le fusioni locali, ti incoraggia a impegnarti spesso e a gestire il set di modifiche che desideri applicare, rispetto ad esempio a SVN in cui è necessario pensare a un commit, poiché in genere viene distribuito a tutti gli altri sviluppatori immediatamente .