git workflow per la separazione dei commit

Question

git workflow per la separazione dei commit

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

2

Le migliori pratiche con git (o qualsiasi VCS per quella materia) dovrebbero essere che ogni commit esegua il minimo cambiamento possibile. Ma questo non corrisponde al mio modo di lavorare.

Ad esempio, di recente ho dovuto aggiungere del codice che verificasse se la versione di un plugin nel mio sistema corrispondesse alle versioni supportate dal sistema. Se non si stampa un avviso che il plugin richiede probabilmente una versione più recente del sistema. Mentre scrivevo quel codice decisi che volevo che gli avvertimenti venissero colorati. Avevo già il codice che colorava il messaggio di errore, quindi ho modificato quel codice. Quel codice era nel modulo di avvio di una voce nel sistema. Il codice di controllo del plugin era in un altro percorso che non utilizzava quel punto di ingresso, quindi spostai il codice di colorizzazione in un modulo separato in modo che entrambi i punti di ingresso potessero usarlo. Inoltre, per testare il mio codice di controllo dei plug-in funziona, devo andare a modificare il codice UI / UX per assicurarmi che indichi all'utente "Devi aggiornare".

Quando tutto è detto e fatto ho modificato 10 file, cambiato le dipendenze, i 2 punti di ingresso ora dipendono entrambi dal codice di colorizzazione, ecc. ecc. Essendo pigro probabilmente sarei solo git add . && git commit -a del tutto. Trascorrere 10-15 minuti a provare a manipolare tutte queste modifiche in 3 o 6 commit più piccoli sembra frustrante e questo solleva la domanda

Esistono flussi di lavoro che funzionano per te o che semplificano questo processo?

Non penso di riuscire a modificare magicamente qualcosa nell'ordine perfetto, dal momento che non conosco quell'ordine fino a quando non comincio a modificare e vedere cosa succede.

So che posso git add --interactive etc ma sembra, almeno per me, un po 'difficile sapere cosa sto afferrando esattamente le modifiche corrette in modo che ogni commit funzioni effettivamente. Inoltre, poiché le modifiche sono contenute nella directory corrente, non sembra che sarebbe facile eseguire test su ciascun commit per assicurarsi che funzionerà a corto di tutte le modifiche. E poi, se si dovesse mettere da parte e poi eseguire i test, se mi fossi perso qualche riga o avessi aggiunto per sbaglio qualche trentina di righe, non ho idea di come avrei recuperato facilmente da quello. (come in entrambi prendere le linee mancanti dalla scorta e poi mettere il resto indietro o prendere le poche linee extra che non avrei dovuto afferrare e inserirle nella memoria per il prossimo commit.

Pensieri? Suggerimenti?

PS: spero che questa sia una domanda appropriata. La guida dice metodologie di sviluppo e processi

git version-control

posta gman 24.08.2014 - 04:11

fonte

2 risposte

Leggi altre domande sui tag git version-control

RefactorException: buona idea o cattiva idea? Disaccoppiamento dei componenti software tramite convenzione di denominazione

score 2 · Answer 1

La cosa da capire è che i più piccoli commit sono più vantaggiosi per te, durante lo sviluppo . Se aspetti che tu sia pronto a spingere per separare i commit, perdi molto aiuto che il tuo strumento potrebbe fornire.

Quello che fai è lavorare sul riconoscimento quando cambi marcia e basta fare un commit o una branch sul posto. Ciò consente al tuo strumento di rispondere a domande come "cosa è cambiato da quando ho iniziato a lavorare sul codice di colorazione?" Ti consente di annullare più facilmente le modifiche parziali quando ti accorgi che stai adottando l'approccio sbagliato, cosa che accade più frequentemente subito dopo aver scritto qualcosa. A volte aiuta anche a impedirti di distrarti in modo distratto da un'attività all'altra. Poiché non vuoi creare un ramo, ti concentri e ottieni la parte su cui stai lavorando in un buon posto per un commit.

Spesso le persone vogliono ripulirlo prima di una spinta in ogni caso, ma la differenza ora è che hai già dei piccoli commit che rompono tutto, potrebbero semplicemente aver bisogno di un po 'di riorganizzazione e consolidamento, che è molto più facile che fare la rottura dopo il fatto.

score 0 · Answer 2

La mia regola generale è di mantenere i commit il più modulari possibile. Quando si sviluppa qualcosa di nuovo, mantengo i commit relativi alle sezioni nei wireframe in modo che si riferiscano a pagine / sezioni. Mantenendo una convenzione di denominazione coerente che altri potrebbero rapidamente cogliere.

Indipendentemente dal numero di file presenti in un commit alla volta, penso che una domanda importante sia che i file nel commit appartengono al messaggio. Trovo che io abbia dei cambiamenti minori, insignificanti che fanno parte del commit che non sono del tutto rilevanti, ma questo è destinato ad accadere di volta in volta. Dopo aver completato le pietre miliari principali, creo abitualmente annotated tags con git tag -a NAME_OF_TAG . Se stai usando qualcosa come gitub, gitlab o bitbucket, puoi scaricare queste sezioni per riferimenti storici.

Di solito mi trovo ad aggiungere file al repository, in punti in cui non ho eseguito il commit dei file che sto già monitorando. È comodo utilizzare git add -u , che aggiunge solo i file che stai monitorando all'area di gestione temporanea. Una volta che i file tracciati sono stati trasferiti, posso passare all'aggiunta e all'impegno dei file appena aggiunti.

Mantenere le cose in ordine sembra essere più difficile quando si è a) refactoring o b) bug. In questi punti mi piace creare rami che aiutano ulteriormente a mantenermi organizzato, oltre a mantenere la linea principale sicura.

Uno strumento utile per la riorganizzazione, git rebase -i . Ho ribadito in un momento in cui dovevo modificare l'ordine di due commit e questo era un modo pratico per modificare la cronologia in modo utile. Rebase ha molto di più di cui è capace, ma questo è solo un esempio. La modifica dei messaggi di commit è possibile anche durante un interactive rebase . Rebasing è un'opzione di cui essere consapevole, mi affiderei a questa come una "prima opzione".