Git Staging: quando mettere in scena? Cosa fare in caso di modifiche successive

Sono piuttosto nuovo nel vasto mondo di Git. Ho letto il manuale e mi sono esercitato, ma sono confuso su alcuni aspetti, che non sono riuscito a capire dopo averlo cercato.

Mi sto chiedendo:

• In un progetto (post primo commit), quando è il momento giusto per mettere in scena i file sorgente? Prima di impegnarsi? Subito dopo aver aggiunto / eliminato o modificato?

• Se i file vengono messi in scena a metà strada tra due commit e poi vengono modificati, cosa succede con Git? Ha bisogno di attenzione ai cambiamenti dei contenuti quando è stato dichiarato e cosa diventa da allora?

• Se creo un nuovo file, lo metto in scena e poi voglio eliminarlo, perché Git mi chiede di usare il flag "-f" e un semplice "git -rm file.ext" non funzionerà?

Ho letto "Che cosa significa palcoscenico" e vari altri argomenti del manuale e altri tutorial su Git, ma come ho già detto, non capisco ancora le questioni di cui sopra.

Quindi, se potessi, rispondi alle domande con le tue parole ed esempi in modo che io abbia maggiori possibilità di capirlo.

Grazie.

Lo scopo dell'area di gestione temporanea è di disporre di uno spazio flessibile per il commit. Penso che questo diventerà più chiaro se si contrappone git a sistemi di controllo versione centralizzati, come sovversione.

Sovversione

In sovversione è possibile selezionare di eseguire il commit di alcuni file della propria copia di lavoro. Ma solo i file completi. Ora: cosa succede se si desidera mettere in scena il file A, non il file Be le parti del file Cche si riferiscono al file Ama non le parti che dipendono dalle modifiche del file B(da allora si avrebbe un problema con la coerenza del commit).

Idiota

Git risolve questo problema fornendo la stadiazione come seconda copia di lavoro. All'interno dell'area di gestione temporanea si sta creando un'istantanea che verrà eseguita (approssimativamente parlando).

Pertanto, all'interno dell'area di gestione temporanea è possibile creare un'istantanea che includa le modifiche Ae una versione del file Cche rifletta solo le modifiche A.

Per le domande specifiche

• Puoi esibirti in qualsiasi momento tu voglia. Personalmente preferisco esibirmi prima di lanciare il commit.

• Quando si verificano modifiche in un file e quindi si modifica quel file nella copia di lavoro, ovviamente non è stato modificato il file in fasi. Puoi decidere se mettere in scena anche quelli o se non mettere in scena questi cambiamenti. Ad esempio, se corri git gui citool, vedrai differenze tra le versioni in scena e non in scena (strumenti belli e semplici per la messa in scena e il commit a livello di linea).

• Git è cauto qui, il che è probabilmente una buona cosa.

Strategia di commit generale: commit granulari

Penso che quando si parla della domanda "Quando dovrei mettere in scena", si dovrebbe anche parlare delle abitudini di impegno.

VCS centralizzato

Nei sistemi di controllo versione centralizzati in cui ti impegni a un server centrale, per i tuoi colleghi era importante che i tuoi commit fossero completi e ben testati. Quindi le persone proverebbero a impegnarsi non così spesso e quindi commettere lo stato dei file completi per ridurre al minimo la possibilità di un errore. Pertanto, un commit tende ad essere blocchi piuttosto grandi che includono molti cambiamenti (se non sono semplici correzioni). Le modifiche in un commit possono essere totalmente indipendenti.

Idiota

In Git un commit viene eseguito localmente, solo il loro push su un server li rende pubblici. Pertanto un impegno è in un certo senso economico . Un commit in senso sovversivo è piuttosto paragonabile a molti git commitseguiti da git push. Questa differenza conta.

Git ti consente di eseguire il commit di singole righe di codice, anche se hai modificato anche altre righe nello stesso file. Ciò offre numerosi vantaggi poiché, ad esempio, è possibile eseguire un bug fix di sicurezza nella riga 100 pur avendo modificato le righe 300-350 introducendo una nuova funzionalità.

• È possibile separare diverse modifiche in diversi commit. Questo li separa bene nella cronologia delle versioni e ti consente persino di ripristinare uno ma non l'altro.
• Il tuo commit non deve necessariamente riflettere uno stato di "compilazione" della tua copia di lavoro (anche se provo a mantenerlo così).

Quindi dov'è il "controllo di qualità" e la garanzia di costruzione in un commit che un utente di sovversione si aspetterebbe? Si è spostato su altre azioni in git. Volete comunque eliminare uno stato funzionante del programma in un repository pubblico. Pertanto, assicurati che i test abbiano esito positivo e che il programma funzioni prima di inviare le modifiche.

Inoltre, prova a utilizzare i rami al massimo. Quando esegui molte piccole modifiche, otterrai una cronologia delle versioni piuttosto grande. Se lavori nei rami, puoi classificare quei commit granulari in base al nome del ramo e poi ricollegarli (l'opzione --no-ffconserverà anche che queste caratteristiche vivevano in un ramo unico).

Vale a dire che è possibile mantenere l'abitudine di fondersi con il masterramo solo se il ramo è in buono stato. Puoi anche utilizzare i tag per tenere traccia delle pietre miliari e dei rilasci.

Ora per tornare alla messa in scena: una volta che hai commesso alcune righe per commit, ti metterai in scena direttamente prima di impegnarti. (Almeno è così che lo faccio).

Penso che lo stia prendendo troppo sul serio. La stadiazione sta semplicemente selezionando gli elementi che desideri includere nel prossimo commit. È molto raramente importante quando o come eseguire la stadiazione; e se si verificano molte modifiche in fasi e non in scena in un dato momento, probabilmente è necessario rivedere il processo di sviluppo.

In un progetto (post primo commit), quando è il momento giusto per mettere in scena i file sorgente? Prima di impegnarsi? Subito dopo aver aggiunto / eliminato o modificato?

Di solito lo faccio subito prima di impegnarmi (a meno che non noti un refuso, quindi devo apportare una correzione dell'ultimo momento e metterla in scena). Il processo è il seguente: modifica, esegui test, stage, commit. Se ti metti in scena prima del test, è probabile che i test falliranno e dovrai apportare modifiche e metterli anche in scena, quindi perché non lasciarlo fino al momento del commit?

Se i file vengono messi in scena a metà strada tra due commit e poi vengono modificati, cosa succede con Git? Ha bisogno di attenzione ai cambiamenti dei contenuti quando è stato dichiarato e cosa diventa da allora?

Ti mostrerà la differenza tra lo stato corrente del repository e (ultimo commit + modifiche organizzate). Quando si mettono in scena alcune delle nuove modifiche, verrà ricalcolato lo stato (ultimo commit + modifiche gestite).

Se creo un nuovo file, lo metto in scena e poi voglio eliminarlo, perché Git mi chiede di usare il flag "-f" e un semplice "git -rm file.ext" non funzionerà?

Ora sto indovinando qui, ma probabilmente è perché le informazioni in fasi potrebbero essere importanti (altrimenti non le metteresti in scena), ma non è ancora sotto il controllo della versione (come un file che puoi rimuovere con git -rm). Quindi gitvuole essere sicuro di sapere cosa stai facendo.