Git Staging: quando mettere in scena? Cosa fare se la modifica si verifica in seguito

Lo scopo dell'area di staging è di avere uno spazio flessibile per il tuo commit. Penso che questo diventerà più chiaro se si contrapporrà git ai sistemi di controllo delle versioni che sono centralizzati, come ad esempio la sovversione.

Subversion

In subversion puoi scegliere di salvare determinati file della tua copia di lavoro. Ma solo i file completi. Ora: cosa succede se vuoi mettere in scena il file A , non il file B , e le parti del file C che si riferiscono al file A ma non le parti che dipendono dalle modifiche nel file B (da allora avresti un problema con la coerenza del commit).

Git

Git risolve questo fornendo la messa in scena come seconda copia di lavoro. All'interno dell'area di staging stai creando un'istantanea che dovrai impegnare (in parole povere).

Quindi all'interno dell'area di staging puoi creare uno snapshot che include le modifiche a A e una versione del file C che riflette solo le modifiche in A .

Per le domande specifiche

• Puoi metterti in scena in qualsiasi punto tu voglia. personalmente preferisco posizionarmi subito prima di avviare il commit.

• Quando si modificano le modifiche in un file e quindi si modifica quel file nella copia di lavoro, non è stato alterato ovviamente il file di stage. Puoi decidere se mettere in scena anche quelle o se non metterle in scena. Cioè se esegui git gui citool vedrai le differenze tra versioni staged e nonstaged (strumenti semplici e semplici per la staging e il commit line-wise).

• Git è prudente qui, che probabilmente è una buona cosa.

Strategia di commit generale: granular commit

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

VCS centralizzato

Nei sistemi di controllo delle versioni centralizzati in cui ci si impegna a un server centrale, era importante per voi collaboratori che i vostri commit fossero completi e ben testati. Quindi le persone proverebbero a impegnarsi non così spesso e poi a commettere lo stato di file completi per minimizzare la possibilità di un errore. Pertanto, i commit tendono ad essere blocchi piuttosto grandi che includono molte modifiche (se non sono semplici correzioni). Le modifiche in un commit possono essere totalmente non correlate.

Git

In Git un commit viene eseguito localmente, solo spingerlo fuori verso un server renderlo pubblico. Pertanto, un commit è economico in un certo senso. Un commit nel senso di sovversione è piuttosto paragonabile a diversi git commit seguiti da git push . Questa differenza è importante.

Git ti permette di commettere singole righe di codice, anche se hai cambiato altre righe nello stesso file. Questo ti dà molti vantaggi dato che puoi ad esempio eseguire un bugfix di sicurezza nella riga 100 mentre hai modificato le linee 300-350 introducendo una nuova funzionalità.

• Puoi separare diverse modifiche in diversi commit. Questo li separa piacevolmente nella cronologia delle tue 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 mantenerla in questo modo).

Quindi dov'è il "controllo di qualità" e la garanzia di costruzione in un commit che un utente di subversione si aspetterebbe? È spostato ad altre azioni in git. Desideri comunque esportare 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 si eseguono molte piccole modifiche, si otterrà una cronologia delle versioni piuttosto grande. Se lavori in succursali, puoi classificare quei commit granulari con il nome del ramo e quindi unirli di nuovo (l'opzione --no-ff conserverà anche che queste funzioni sono vissute in un ramo univoco).

vale a dire. puoi mantenere l'abitudine di unire solo al ramo master , se il ramo si trova in uno stato buono . Puoi anche utilizzare i tag per tracciare traguardi e pubblicazioni.

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

Penso che lo stia prendendo troppo sul serio. Staging sta semplicemente selezionando le cose che vuoi includere nel prossimo commit. Raramente è importante quando o come si fa la messa in scena; e se hai un sacco di modifiche graduali e non pianificate in un dato momento, probabilmente hai bisogno di rivedere il tuo processo di sviluppo.

In a project (post first commit), when is the right moment to stage source files? Right before committing? Right after adding/deleting or modifying?

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

If files are staged midway between two commits, and then they get modified, what happens with Git? Does it need care about content changes when it was stated and what it become since?

Ti mostrerà la differenza tra lo stato corrente del repository e (ultimo commit + cambiamenti di stage). Quando metti in scena alcune delle nuove modifiche, verrà solo ricalcolato lo stato (ultimo commit + modifiche temporanee).

If I create a new file, stage it and then want to delete it, why does Git ask me to use "-f" flag and a simple "git -rm file.ext" won't work?

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