Tutorial Git - Git Workflow

1. git add
2. git commit

Come abbiamo appena appreso, l’aggiunta di un file o il suo commit è fondamentalmente un processo in due fasi.

git add

Dopo aver cambiato un file e averlo salvato, questo file sul nostro computer è diverso dal file nel nostro repository, perché nel repository è ancora lo stesso contenuto prima di questa modifica. Se si digita git status, si può vedere che Git sa che il file è stato aggiornato.

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   test1.txt

no changes added to commit (use "git add" and/or "git commit -a")

Come suggerito da Git, usiamo git add per aggiornare i file che saranno impegnati.

$ git add test1.txt

Ora, si potrebbe impegnare questo file aggiornato dall’area di staging al repository.

A volte, abbiamo aggiornato più file e naturalmente potremmo aggiungere file in questo modo,

$ git add test1.txt test2.txt test3.txt

Ma ti porta un gran mal di testa se hai un mucchio di file o il nome del file è troppo lungo. Git ha una scorciatoia per aggiungere tutti i file aggiornati e i file non tracciati all’area di staging,

$ git add .

Qui, . significa tutti i file che sono diversi dal repository.

git commit

Abbiamo mostrato come usare git commit quando abbiamo introdotto altre caratteristiche di Git. Fondamentalmente, git commit spinge l’area di staging al repository, e si consiglia vivamente di aggiungere il messaggio di commit per descrivere cosa si è cambiato per questo specifico commit. Si possono ottenere tutte le informazioni del registro di commit con il comando git log.

Impegnati direttamente nel repository

Prima di procedere a ciò che ci impegniamo, dobbiamo aggiungere delle modifiche all’area di allestimento. Poi potremmo impegnarle. Ma non c’è davvero bisogno di aggiungerle all’area di allestimento. In primo luogo, perché sappiamo che questi cambiamenti li vogliamo nel nostro progetto finale, nel nostro repository o sul server affinché tutti abbiano i file aggiornati.

Quindi quello che potremmo fare è controllare git status primo, in modo da sapere cosa è stato modificato nella copia di lavoro. Poi potremmo usare direttamente git commit prima ancora di aggiungere queste modifiche all’area di staging.

$ git commit -a -m "commit message here."

Quello che facciamo qui è usare una scorciatoia invece di aggiungerla all’area di staging. Ma questo è utile solo in certe situazioni, ogni volta che si usa questo comando, bisogna fare attenzione perché prenderà tutto ciò che si trova nella copia di lavoro e lo spingerà direttamente nel repository.

Modificare un impegno

Potevamo arrivare a una situazione dopo un commit, troviamo un errore di battitura o altri piccoli difetti nel codice. Naturalmente, è possibile rivedere i codici e apportare di nuovo le modifiche al repository. Ma quello che potremmo fare è riscrivere il commit più recente, e l’ultimo commit sarà riscritto con la nuova modifica.

Il flag --amend che segue git commit dice Git che questo commit sostituirà il commit precedente che non sarà più nel tuo ramo di lavoro.

$ git commit --amend -m "new information is updated"