Stile di commit Git: tutti i file modificati in una volta o uno alla volta?

Question

Sto salvando il mio lavoro di notte con un singolo commit per molti file. Mi chiedo se sarebbe meglio impegnarsi per ogni file, ma questo sembra molto più lavoro.

Non ho alcun problema con il modo in cui le cose sono ora ma ho intenzione di mettere il mio codice su GitHub e voglio che sia facile da capire.

Mi chiedo che cosa sta facendo il resto di voi che usano git. Inoltre, se tu potessi tipo di precisarlo per me. Sono nuovo di Git e ho usato TortoiseGit e gitk in Windows.

Answer 1

Quando commettere e cosa commettere è un'arte e non ci sono regole in bianco e nero. Detto questo, ci sono abitudini che sono più facili da capire rispetto ad altre.

In generale, penso che dovresti ottimizzare il tuo impegno per la comprensibilità - se torni indietro e leggi il diff per il commit, puoi capire cosa hai realizzato nelle modifiche?

Se si vuole essere più precisi, ecco una lunga lista di quello che penso siano cose da fare e da non fare:

• Non commettere dopo ogni singolo piccolo cambiamento - ogni linea è cambiato, ogni file modificato , ecc.
• Non lavorare per un giorno intero e fare un gigantesco commit alla fine della giornata.
• Esegui commit separati per caratteristiche diverse, ad es. sviluppo di feature foo vs. correzione del bug # 2.
• Esegui un commit separato per spostare/rinominare i file, perché è più facile per Git tracciare in questo modo.
• Pensa all'ottimizzazione per la riverberazione: se non ti piace una modifica che hai apportato, è facile annullarla anche dopo aver aggiunto le nuove modifiche?

Answer 2

"Facile da capire" significa anche:

• commette che rappresenta non solo "checkpoint" (come si farebbe se si impegna dopo ogni modifica del file), ma uno stato coerente del codice di
• facile da git bisect (cioè ogni commit dovrebbe rappresentare un cambiamento in un compito , che compila e aggiungere un'evoluzione o di una nuova funzionalità, e non un "checkpoint commit", che renderebbe l'git bisect fallisce troppo presto)

Vedere "understanding the Git workflow" per più: è necessario distinguere:

rami

• privati ​​(che non avete mai push), dove si può commettere in pratica in qualsiasi momento, e
• rami pubblici (che si vuole spingere su GitHub), che deve essere pulito e avere commesse significative.

Quindi prestare attenzione alla "fast-forward" merge that Git uses by default: non dimenticare di ripulire la storia di rami che si sta per fondersi in quel modo in rami pubblici.