Accidentalmente inclusi cambiamenti non correlati nei commit

Question

Accidentalmente inclusi cambiamenti non correlati nei commit

#1 da (9 voti)
#2 da (1 voti)
#3 da (0 voti)

8

Il mio approccio personale a un commit Git è che ogni commit dovrebbe includere una unità di cambiamento , nella sua completezza.

Quando sviluppo, di solito mi concentro su tali unità. Ma a volte, la mia attenzione si allontana da qualche altra parte e io lavoro per un po 'su un'altra unità. Questo probabilmente non è ottimale, ma ho imparato a impegnarmi attentamente ( git add --interactive è un mio buon amico).

Tuttavia, potrebbe accadere che io dimentichi di mettere in scena selettivamente le mie modifiche e invece impegni l'intero file, credendo che tutte le modifiche che vedo nel diff siano effettivamente correlate alla stessa unità, anche se potrebbero esserci dei cambiamenti o due completamente non correlato.

Quindi I git push .

È pericoloso? Devo fare uno sforzo per modificare il commit in modo che includa solo le modifiche previste? La mia preoccupazione principale è che chiunque guardi la storia vedrà il cambiamento e probabilmente si gratterà la testa per diversi minuti prima di rendersi conto che è molto probabilmente un errore. Peggio ancora, posso immaginare che il cambiamento sembrerà anche relativo e il programmatore potrebbe non riconoscere l'errore.

Il problema è che, poiché ho già spinto, non posso tranquillamente riscrivere la cronologia del server, quindi probabilmente dovrei prima ripristinare il commit, dividerlo correttamente e eseguire nuovamente il commit. In alternativa, potrei semplicemente modificare il commit con un messaggio di commit migliore, ma dovrei essere davvero molto veloce poiché richiede anche la riscrittura della cronologia. Come ultima risorsa, potrei semplicemente impegnare l'unità su cui stavo lavorando come dopo, lasciando una nota che c'è un cambiamento relativo nel commit precedente (ma questo sembra sbagliato).

Comprendo che in una configurazione multi-sviluppatore con un flusso di lavoro appropriato per la revisione del codice questo probabilmente non accadrà. Capisco anche che se io sono l'unico sviluppatore di un progetto, quindi la riscrittura della cronologia è la soluzione migliore per questo.

git

posta Robert Rossmann 04.06.2015 - 16:19

fonte

3 risposte

1

Quando ciò accade, non è un grosso problema semplicemente ripristinare la modifica nel prossimo commit. Aggiungi un messaggio di commit appropriato ( Removing the XYZ that I accidentally added in C92A891 ) sarà sufficiente per altri sviluppatori per capire nella revisione del codice.

Invece di preoccuparti di correggere qualsiasi incidente specifico, cerca di evitare la situazione in primo luogo.

Questo è il vero problema:

However, it could happen that I forget to selectively stage my changes and instead commit the whole file

Dovresti prendere l'abitudine di mai impegnare un intero file (o peggio di tutto il tuo intero spazio di lavoro!). Sempre tieni il comando riga per riga o da un'intera Hunk che hai esaminato.

Quando ti impegni in questo modo (il che sembra che tu stia facendo la maggior parte del tempo) le modifiche involontarie hanno molte meno probabilità di intrufolarsi nei tuoi commit.

risposta data 18.02.2016 - 22:52

fonte

0

Sembra che tu abbia un repository locale sul tuo computer e un repository condiviso con i tuoi colleghi su un server. Perché hai un solo repository sul tuo computer locale? Di solito ne ho almeno cinque, quindi posso lavorare su una cosa in un repository, correggere un bug in un'altra senza toccare il primo repository, che potrebbe essere in uno stato incompleto, e così via.

risposta data 14.06.2015 - 08:35

fonte

Leggi altre domande sui tag git

Do $ _POST, $ _GET, etc violano il principio di incapsulamento? Va bene avere dipendenze all'interno di una classe che deve essere scambiabile?

score 9 · Accepted Answer

La cronologia degli impegni è di vitale importanza, ma per 3 motivi:

unione con un'altra parte. Devi estrarre i pezzi da un ramo e incollarli altrove, è importante avere tutti i pezzi che vuoi lì dentro e niente che non vuoi. Quindi se il tuo commit "disordinato" contiene modifiche intese per la funzione su cui stai lavorando (e non, ad esempio, un commit accidentale di qualcos'altro), allora sei bravo.
Controllo di ciò che è successo qualche tempo dopo - in genere per determinare quando è stato introdotto un particolare bug o funzionalità. In questo caso, non importa ciò che è nei commit finché puoi individuare la modifica che ti interessa.
Revisione del codice. Buone revisioni tra pari sono impegnate e quindi riviste (non tenere il processo dev / commit aspettando un revisore!) E in questi casi il revisore vorrà capire quali modifiche sono state apportate. Tuttavia, generalmente un revisore sarà più interessato alle modifiche complessive - provare a rivedere i commit che sono stati fatti, ripristinati, rifatti è un esercizio di perdita di tempo rispetto alla revisione di tutti e 3 i commit contemporaneamente.

Quindi, anche se l'unità di lavoro commette il suono ideale, non sono nulla su cui insistere in termini pratici. Cercherò di mantenere i commit sensibili, e l'unità di lavoro è un buon modo per mantenere i commit sani di mente, ma non preoccuparti di cercare di manipolare la cronologia dei commit solo per tenere in ordine i commit. È come aggiornare un file di codice per allineare tutte le parentesi nel modo che preferisci: bello, ma inutile.

Ora, se hai impegnato un po 'di lavoro destinato a un ramo diverso, ripristinalo e affidalo correttamente al ramo destro. Questo è importante, ma se hai aggiornato un po 'di codice server quando hai lavorato sulla GUI ... non devi preoccuparti di questo.