Usuário:Musa
(→Il Proprio Editor) |
(→Git) |
||
(45 edições intermediárias de 2 usuários não apresentadas) | |||
Linha 1: | Linha 1: | ||
− | == | + | == Django == |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | == | + | == Python == |
== Git == | == Git == | ||
Linha 34: | Linha 26: | ||
$git config --global core.editor emacs | $git config --global core.editor emacs | ||
− | + | * Il Proprio Diff | |
Un'altra utile opzione, che si potrebbe voler configurare, è lo strumento diff, predefinito, da usare per risolvere i conflitti di merge (fusione, ndt). Per usare vimdiff: | Un'altra utile opzione, che si potrebbe voler configurare, è lo strumento diff, predefinito, da usare per risolvere i conflitti di merge (fusione, ndt). Per usare vimdiff: | ||
$git config --global merge.tool vimdiff | $git config --global merge.tool vimdiff | ||
− | + | ||
+ | * Controllare le Impostazioni | ||
Per controllare le proprie impostazioni, si può usare il comando git config --list, che elenca tutte le impostazioni di Git, fatte fino a questo punto: | Per controllare le proprie impostazioni, si può usare il comando git config --list, che elenca tutte le impostazioni di Git, fatte fino a questo punto: | ||
musa@amilo:~/mocambos$ git config --list | musa@amilo:~/mocambos$ git config --list | ||
Linha 51: | Linha 44: | ||
$ git config user.name | $ git config user.name | ||
musa jedo | musa jedo | ||
− | + | ||
+ | * Ottenere Aiuto | ||
Questi comandi sono utili, perché puoi accedere ad essi da ogni dove, anche se sei offline. Se il manuale e questo libro non sono sufficienti e hai bisogno di un aiuto più diretto da una persona, puoi provare i canali #git o #github, sul server IRC di Freenode (irc.freenode.com). Questi canali sono regolarmente frequentati da centinaia di persone che conoscono molto bene Git e saranno davvero felici di aiutarti. | Questi comandi sono utili, perché puoi accedere ad essi da ogni dove, anche se sei offline. Se il manuale e questo libro non sono sufficienti e hai bisogno di un aiuto più diretto da una persona, puoi provare i canali #git o #github, sul server IRC di Freenode (irc.freenode.com). Questi canali sono regolarmente frequentati da centinaia di persone che conoscono molto bene Git e saranno davvero felici di aiutarti. | ||
Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale di aiuto per ogni comando di Git: | Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale di aiuto per ogni comando di Git: | ||
Linha 63: | Linha 57: | ||
$echo "$(git –version)" | $echo "$(git –version)" | ||
− | + | * Creare un Repository Vuoto | |
Per comprendere git non ci servirà né Xcode né altri programmi. Ci baseremo infatti esclusivamente sul terminale. Avviamo quindi il terminale e creiamo la cartella “mocambos git” dove meglio ci piace. (ricordo che nel terminale cd è il comando per cambiare directory e mkdir quello per crearne una nuova). | Per comprendere git non ci servirà né Xcode né altri programmi. Ci baseremo infatti esclusivamente sul terminale. Avviamo quindi il terminale e creiamo la cartella “mocambos git” dove meglio ci piace. (ricordo che nel terminale cd è il comando per cambiare directory e mkdir quello per crearne una nuova). | ||
musa@amilo:~$ mkdir mocambos | musa@amilo:~$ mkdir mocambos | ||
Linha 108: | Linha 102: | ||
musa@amilo:~/mocambos$ git log | musa@amilo:~/mocambos$ git log | ||
commit c03619ddb1c07958f6052ef96110dba6b27bb8b8 | commit c03619ddb1c07958f6052ef96110dba6b27bb8b8 | ||
− | Author: Musa < | + | Author: Musa <musa jedo@exmple.org> |
Date: Fri Aug 2 15:24:18 2013 +0200 | Date: Fri Aug 2 15:24:18 2013 +0200 | ||
add emphasis | add emphasis | ||
Linha 128: | Linha 122: | ||
* git rm: marca un file come da rimuovere sul repository | * git rm: marca un file come da rimuovere sul repository | ||
(*) l’indicazione dello stato corrente necessita una spiegazione: all’interno del repository vengono mantenuti dei riferimenti ai diversi oggetti commit, il riferimento HEAD punta al commit corrente e viene portato avanti automaticamente quando si effettua un nuovo commit. | (*) l’indicazione dello stato corrente necessita una spiegazione: all’interno del repository vengono mantenuti dei riferimenti ai diversi oggetti commit, il riferimento HEAD punta al commit corrente e viene portato avanti automaticamente quando si effettua un nuovo commit. | ||
− | + | * Git Branches | |
I progetti non hanno mai una vita lineare, neanche nel mondo ideale. Ci sono sempre almeno un paio di versioni “funzionanti” nelle quali si prova ad aggiungere nuove funzionalità o rimuovere vecchi problemi. git tiene conto di queste esigenze e risponde con la funzionalità chiamata branch. In un repository possono coesistere più branch contemporaneamente, il primo viene creato di default e si chiama master tutti gli altri possono essere creati successivamente dall’utente. | I progetti non hanno mai una vita lineare, neanche nel mondo ideale. Ci sono sempre almeno un paio di versioni “funzionanti” nelle quali si prova ad aggiungere nuove funzionalità o rimuovere vecchi problemi. git tiene conto di queste esigenze e risponde con la funzionalità chiamata branch. In un repository possono coesistere più branch contemporaneamente, il primo viene creato di default e si chiama master tutti gli altri possono essere creati successivamente dall’utente. | ||
Per creare il nuovo branch 'develop' occorre digitare: | Per creare il nuovo branch 'develop' occorre digitare: | ||
Linha 172: | Linha 166: | ||
Per saltare da un ramo ad un altro si usa il comando: | Per saltare da un ramo ad un altro si usa il comando: | ||
$ git checkout master | $ git checkout master | ||
− | + | ||
+ | * Merge | ||
Terminate le modifiche effettuate sul branch nuovo_ramo è adesso il momento riportarle sul branch master. Purtroppo non abbiamo garanzia che nessuno abbia intanto modificato i file del branch master, anzi, in uno sviluppo condiviso, questa è la norma, quindi incrociamo le dita e speriamo che non ci siano conflitti di sorta. | Terminate le modifiche effettuate sul branch nuovo_ramo è adesso il momento riportarle sul branch master. Purtroppo non abbiamo garanzia che nessuno abbia intanto modificato i file del branch master, anzi, in uno sviluppo condiviso, questa è la norma, quindi incrociamo le dita e speriamo che non ci siano conflitti di sorta. | ||
Switchiamo sul branch master e digitiamo: | Switchiamo sul branch master e digitiamo: | ||
Linha 186: | Linha 181: | ||
se un giorno decidessimo che il branch develop non ci serve più, cancelliamolo | se un giorno decidessimo che il branch develop non ci serve più, cancelliamolo | ||
$git branch -d develop | $git branch -d develop | ||
− | + | ||
+ | * Eliminare un ramo | ||
Dopo aver usato un ramo e dopo aver fatto il merge nel ramo principale possiamo decidere di eliminarlo dal nostro repository. | Dopo aver usato un ramo e dopo aver fatto il merge nel ramo principale possiamo decidere di eliminarlo dal nostro repository. | ||
$ git branch -d <nome_ramo_locale> | $ git branch -d <nome_ramo_locale> | ||
$ git branch -d -r <nome_ramo_remoto> | $ git branch -d -r <nome_ramo_remoto> | ||
Questa prima parte della guida all’uso di git termina qui, nella prossima puntata affronteremo la condivisione dello stesso progetto su più utenti, anche attraverso internet. | Questa prima parte della guida all’uso di git termina qui, nella prossima puntata affronteremo la condivisione dello stesso progetto su più utenti, anche attraverso internet. | ||
− | + | ||
+ | * Prossimo Utilizzando git per la collaborazione | ||
+ | |||
+ | == Git-annex == | ||
+ | git-annex/ | ||
+ | git-annex è grande. Si tratta di una estensione a git che permette di gestire i file con git senza peraltro riuscire a check-in git-annex fa sostituendo ogni file con un link simbolico che punta al reale contenuto nella directory git / annex (dal nome di un checksum del file di contenuti). Solo il collegamento simbolico viene controllato in git. | ||
+ | ecco come fare per arrivare dal nulla per il monitoraggio di un file con git-annex: | ||
+ | * Creazione di un repository | ||
+ | Basta dire che una descrizione del repository. | ||
+ | musa@amilo:~$ mkdir Bocs | ||
+ | musa@amilo:~$ cd Bocs/ | ||
+ | musa@amilo:~/Bocs$ git init | ||
+ | Initialized empty Git repository in /home/musa/Bocs/.git/ | ||
+ | musa@amilo:~/Bocs$ git annex init "amilo" | ||
+ | init amilo ok | ||
+ | (Recording state in git...) | ||
+ | * aggiungere un remoto: | ||
+ | Come qualsiasi altro repository git, git-annex repository hanno remoto. Cominciamo con l'aggiunta di un drive USB come un remoto. | ||
+ | se il tuo drive usb non installato, può installarlo con il commando sudo/mount/media/nome usb drive. | ||
+ | musa@amilo:/$sudo mount /media/6FFE-842D | ||
+ | per spostarlo nel usb drive con il commando cd /media/nome usb drive | ||
+ | musa@amilo:/$cd /media/6FFE-842D | ||
+ | clonare nostro directory con comando git clone ~/Bocs | ||
+ | musa@amilo:/media/6FFE-842D$ git clone ~/Bocs | ||
+ | Initialized empty Git repository in /media/6FFE-842D/Bocs/.git/ | ||
+ | warning: remote HEAD refers to nonexistent ref, unable to checkout. | ||
+ | spostare nel directory Bocs | ||
+ | musa@amilo:/media/6FFE-842D$cd Bocs | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git annex init "portable USB drive" | ||
+ | init portable USB drive | ||
+ | Detected a crippled filesystem. | ||
+ | Enabling direct mode. | ||
+ | Detected a filesystem without fifo support. | ||
+ | Disabling ssh connection caching. | ||
+ | ok | ||
+ | (Recording state in git...) | ||
+ | |||
+ | per aggiunger usb drive remoto con computer portatile amilo | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git remote add amilo ~/Bocs | ||
+ | aggiungere computer portatile amilo remoto con il drive USB | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ cd ~/Bocs | ||
+ | musa@amilo:~/Bocs$ git remote add usbdrive /media/6FFE-842D/Bocs | ||
+ | Tutto questo è la configurazione standard di repository ad hoc distribuito git. L'unica git-annex specifica parte sta dicendo che il nome del nuovo repository creato sul drive USB. | ||
+ | Si noti che entrambi i pronti contro termine sono impostati come remoto l'uno dell'altro. Ciò consente di ottenere sia annex file dall'altro. Avrai voglia di farlo, anche se si sta usando git in modo più centralizzato. | ||
+ | *aggiuntiamo un file nel directory Bocs al computer portatile amilo: | ||
+ | musa@amilo:~/Bocs$ cp /home/musa/zaghawa.jpg zaghawa.jpg | ||
+ | musa@amilo:~/Bocs$ git annex add . | ||
+ | add zaghawa.jpg (checksum...) ok | ||
+ | (Recording state in git...) | ||
+ | musa@amilo:~/Bocs$ git commit -a -m added | ||
+ | [master (root-commit) d94ecb8] added | ||
+ | 1 files changed, 1 insertions(+), 0 deletions(-) | ||
+ | create mode 120000 zaghawa.jpg | ||
+ | Quando si aggiunge un file alla annex e commit, solo un link simbolico per il contenuto annex si impegna. Il contenuto stesso è memorizzato nel backend git-annex. | ||
+ | * ottenere il contenuto del file: | ||
+ | Un repository non ha sempre tutto il contenuto del file annex disponibile. Quando è necessario il contenuto di un file, è possibile usare "git annex ottenere" per renderlo disponibile. | ||
+ | Possiamo usare questo per copiare tutto nella dependance del computer portatile per il drive USB. | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git fetch amilo; git merge amilo/master | ||
+ | remote: Counting objects: 9, done. | ||
+ | remote: Compressing objects: 100% (6/6), done. | ||
+ | remote: Total 8 (delta 0), reused 0 (delta 0) | ||
+ | Unpacking objects: 100% (8/8), done. | ||
+ | From /home/musa/Bocs | ||
+ | * [new branch] git-annex -> amilo/git-annex | ||
+ | * [new branch] master -> amilo/master | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git annex get . | ||
+ | get zaghawa.jpg (merging amilo/git-annex origin/git-annex into git-annex...) | ||
+ | (Recording state in git...) | ||
+ | (from amilo...) | ||
+ | SHA256E-s56356--f4012fc17b574a5935e95219e9ec783deb401a70619c4c336c6dc71d0785b8a7.jpg | ||
+ | 56356 100% 11.25MB/s 0:00:00 (xfer#1, to-check=0/1) | ||
+ | |||
+ | sent 56508 bytes received 31 bytes 113078.00 bytes/sec | ||
+ | total size is 56356 speedup is 1.00 | ||
+ | ok | ||
+ | (Recording state in git...) | ||
+ | *sincronizzazione:- | ||
+ | Si noti che nell'esempio precedente, si doveva git fetch e unire dal computer portatile prima. Ciò consente git-annex sapere cosa è cambiato nel computer portatile, e quindi conosce i file lì presenti e possono farli. | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git annex sync | ||
+ | add zaghawa.jpg (checksum...) ok | ||
+ | (Recording state in git...) | ||
+ | commit | ||
+ | (Recording state in git...) | ||
+ | ok | ||
+ | pull origin | ||
+ | From /home/musa/Bocs | ||
+ | e0231e2..44f655e git-annex -> origin/git-annex | ||
+ | * [new branch] master -> origin/master | ||
+ | ok | ||
+ | pull amilo | ||
+ | ok | ||
+ | push origin | ||
+ | Counting objects: 32, done. | ||
+ | Delta compression using up to 2 threads. | ||
+ | Compressing objects: 100% (18/18), done. | ||
+ | Writing objects: 100% (24/24), 2.17 KiB, done. | ||
+ | Total 24 (delta 3), reused 0 (delta 0) | ||
+ | Unpacking objects: 100% (24/24), done. | ||
+ | To /home/musa/Bocs | ||
+ | * [new branch] git-annex -> synced/git-annex | ||
+ | * [new branch] master -> synced/master | ||
+ | ok | ||
+ | push amilo | ||
+ | Everything up-to-date | ||
+ | ok | ||
+ | Dopo l'esecuzione di sincronizzazione, il repository sarà aggiornato con tutte le modifiche apportate ai propri remoto, ed eventuali cambiamenti nel repository sarà spinto fuori per i suoi remoti, dove una sincronizzazione li porterà. Ciò è particolarmente utile quando si usa git in modo distribuito, senza un repository nudo centrale. Vedere sincronizzazione per i dettagli. | ||
+ | Si noti che la sincronizzazione sincronizza solo i metadati sui file che è memorizzato in git. Non sincronizzare il contenuto dei file, che sono gestiti da git-annex. | ||
+ | *usando ssh remoto: | ||
+ | Finora in questa procedura dettagliata, git-annex è stato utilizzato con un repository remoto su un drive USB. Ma può essere utilizzato anche con un remoto git che è veramente remota, un host accessibile da ssh. | ||
+ | Diciamo che avete un desktop sulla stessa rete del computer portatile e vuole clonare annex del portatile ad esso: | ||
+ | $git clone ssh://mio portable/home/musa/Bocs | ||
+ | $cd ~/Bocs | ||
+ | $git annex init "mio Scrivania" | ||
+ | Ora è possibile ottenere i file e saranno trasferiti (usando rsync via ssh): | ||
+ | $git annex get zaghawa.jpg | ||
+ | get my_cool_big_file (getting UUID for origin...) (from origin...) | ||
+ | SHA256E-s56356--f4012fc17b574a5935e95219e9ec783deb401a70619c4c336c6dc71d0785b8a7.jpg 100% 2159 2.1KB/s 00:00 | ||
+ | ok | ||
+ | Quando si elimina file, git-annex volontà ssh verso il remoto e assicurarsi che il contenuto del file è ancora lì prima di rimuoverla a livello locale: | ||
+ | git annex drop zaghawa | ||
+ | drop zaghawa.jpg (checking origin..) ok | ||
+ | * spostamento del contenuto di file tra i repository: | ||
+ | Spesso si vuole spostare alcuni contenuti dei file da un archivio ad un altro uno. Ad esempio, rigido del computer portatile è sempre pieno, il tempo di spostare alcuni file su un disco esterno prima di passare un altro file da un file server al vostro computer portatile. Farlo a mano (usando git annex ottenere e git annex calo) è possibile, ma un po 'di dolore. git annex mossa rende molto facile. | ||
+ | musa@amilo:~/Bocs$ git annex move zaghawa.jpg --to usbdrive | ||
+ | * utilizzando tag e rami: | ||
+ | Come git, git-annex si blocca su ogni versione di un file (di default), in modo da poter rendere i tag e rami, e può controllare fuori in seguito a guardare i vecchi file. | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git tag 1.0 | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ rm -f zaghawa.jpg | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git commit -m deleted | ||
+ | # On branch master | ||
+ | # Changed but not updated: | ||
+ | # (use "git add/rm <file>..." to update what will be committed) | ||
+ | # (use "git checkout -- <file>..." to discard changes in working directory) | ||
+ | # | ||
+ | # deleted: zaghawa.jpg | ||
+ | # | ||
+ | no changes added to commit (use "git add" and/or "git commit -a") | ||
+ | musa@amilo:/media/6FFE-842D/Bocs$ git checkout 1.0 | ||
+ | D zaghawa.jpg | ||
+ | Note: checking out '1.0'. | ||
+ | You are in 'detached HEAD' state. You can look around, make experimental | ||
+ | changes and commit them, and you can discard any commits you make in this | ||
+ | state without impacting any branches by performing another checkout. | ||
+ | If you want to create a new branch to retain commits you create, you may | ||
+ | do so (now or later) by using -b with the checkout command again. Example: | ||
+ | git checkout -b new_branch_name | ||
+ | HEAD is now at d18d244... git-annex automatic sync | ||
+ | Naturalmente, quando si git checkout un vecchio ramo, alcune vecchie versioni di file potrebbero non essere disponibili a livello locale, e possono essere memorizzate in qualche altro repository. È possibile utilizzare git annex arrivare a farli come al solito. | ||
+ | * gestire automaticamente il contenuto: | ||
+ | Una volta che si dispone di più repository, e forse avete configurato numcopies, ogni file può avere molte più copie del necessario, o forse meno di quanto avrebbe voluto. Come gestire questo? | ||
+ | Il whereis sottocomando può essere usato per vedere quante copie di un file sono noti, ma poi si deve decidere cosa prendere o cadere. In questo esempio, non vi sono forse abbastanza copie del primo file, e troppi del secondo file. | ||
+ | $cd /media/6FFE-842D/ | ||
+ | $git annex whereis | ||
+ | whereis zaghawa.jgp (2 copies) | ||
+ | 0c443de8-e644-11df-acbf-f7cd7ca6210d -- amilo | ||
+ | 62b39bbe-4149-11e0-af01-bb89245a1e61 -- here (usb drive) |
Edição atual tal como às 08h36min de 2 de setembro de 2013
Conteúdo |
Django
Python
Git
GIT è un sistema di controllo di versione distribuito il quale software viene rilasciato in maniera open source. Ma cosa significa? Significa che tramite git è possibile tenere traccia delle modifiche effettuate su un insieme di file. Modifiche ai singoli file, aggiunte e cancellazione di file vengono memorizzate in uno storico. E' possibile lavorare in più persone sugli stessi file, o su una loro copia (clonatura) e poi fondere le modifiche tramite un sistema che aiuta nella soluzione di eventuali conflitti. L’idea di fondo è avere macchine in comunicazione tra loro in maniera distribuita, non c’è un server che si interfaccia con un client. E’ possibile realizzare due tipi di repository: locale o remoto (GitHub o Bitbucket), entrambe le possibilità verranno delineate negli articoli successivi, oggi mi soffermo sulle basi per acquisire padronanza con questo meraviglioso sistema.
- Git
GIT è un sistema di controllo di versione distribuito il quale software viene rilasciato in maniera open source. Ma cosa significa? Significa che tramite git è possibile tenere traccia delle modifiche effettuate su un insieme di file. Modifiche ai singoli file, aggiunte e cancellazione di file vengono memorizzate in uno storico. E' possibile lavorare in più persone sugli stessi file, o su una loro copia (clonatura) e poi fondere le modifiche tramite un sistema che aiuta nella soluzione di eventuali conflitti. L’idea di fondo è avere macchine in comunicazione tra loro in maniera distribuita, non c’è un server che si interfaccia con un client. E’ possibile realizzare due tipi di repository: locale o remoto (GitHub o Bitbucket), entrambe le possibilità verranno delineate negli articoli successivi, oggi mi soffermo sulle basi per acquisire padronanza con questo meraviglioso sistema.
- storia
Git è stato creato nel 2005 da Linus Torvalds, l'inventore del sistema operativo Linux. Inizialmente è stato creato per la scarsa capacità di progetti datati come CVS e Subversion nel gestire grossi progetti come quello del Kernel di Linux e per problemi di diritti con il software proprietario utilizzato fino ad allora, chiamato BitKeeper.
- Prima Configurazione di git
Prima di utilizzare Git bisogna attuare alcune configurazioni basilari: Inserire l’utente è fondamentale per fare in modo che i commit non escano con nomi casuali e irriconoscibili.
- La Propria Identità
La prima cosa che occorrerebbe fare, quando si installa Git, è impostare il proprio nome utente e indirizzo e-mail. Ciò è importante, perché ogni commit di Git usa queste informazioni, che vengono incapsulate nei commit che si fanno:
$ git config --global user.name "musa jedo" $ git config --global user.email musajedo@example.com
- Il Proprio Editor
Ora che è configurata la propria identità, si può configurare l'editor di testo predefinito, da usare quando Git avrà bisogno di inserire un messaggio. Per impostazione predefinita, Git usa l'editor di testo predefinito del sistema, che generalmente è Vi o Vim. Se vuoi usare un editor di testo differente, come Emacs, puoi fare come segue:
$git config --global core.editor emacs
- Il Proprio Diff
Un'altra utile opzione, che si potrebbe voler configurare, è lo strumento diff, predefinito, da usare per risolvere i conflitti di merge (fusione, ndt). Per usare vimdiff:
$git config --global merge.tool vimdiff
- Controllare le Impostazioni
Per controllare le proprie impostazioni, si può usare il comando git config --list, che elenca tutte le impostazioni di Git, fatte fino a questo punto:
musa@amilo:~/mocambos$ git config --list user.email=musajedo@example.com user.name=Musa core.editor=emancs core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true
La stessa chiave può comparire più volte, perché Git legge la stessa chiave da file differenti (/etc/gitconfig e ~/.gitconfig, per esempio). In questo caso, Git usa l'ultimo valore per ogni chiave unica che vede. Per controllare quale sia il valore di una chiave, ritenuto da Git usare, git config {key}:
$ git config user.name musa jedo
- Ottenere Aiuto
Questi comandi sono utili, perché puoi accedere ad essi da ogni dove, anche se sei offline. Se il manuale e questo libro non sono sufficienti e hai bisogno di un aiuto più diretto da una persona, puoi provare i canali #git o #github, sul server IRC di Freenode (irc.freenode.com). Questi canali sono regolarmente frequentati da centinaia di persone che conoscono molto bene Git e saranno davvero felici di aiutarti. Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale di aiuto per ogni comando di Git:
$ git help $ git --help $ man git
Per esempio, puoi avere la pagina del manuale di aiuto, per il comando config, lanciando
$ git help config
Per controllare la versione di git
$git --version $echo "$(git –version)"
- Creare un Repository Vuoto
Per comprendere git non ci servirà né Xcode né altri programmi. Ci baseremo infatti esclusivamente sul terminale. Avviamo quindi il terminale e creiamo la cartella “mocambos git” dove meglio ci piace. (ricordo che nel terminale cd è il comando per cambiare directory e mkdir quello per crearne una nuova).
musa@amilo:~$ mkdir mocambos musa@amilo:~$ cd mocambos/
Dall’interno della cartella “mocambos” appena creata digitiamo il comando
musa@amilo:~/mocambos$ git init
Questo inizializza un repository vuoto nella cartella in cui viene dato il comando. Vedremo quindi un messaggio simile a questo:
Initialized empty Git repository in /home/fasher/mocambos/.git/
Abbiamo appena creato il nostro primo repository. Possiamo infatti vedere che all’interno della cartella “mocambos ” è stata creata una cartella nascosta “.git”
musa@amilo:~/mocambos$ ls -laF totale 12 drwxr-xr-x 3 musa musa 4096 2013-08-02 14:57 ./ drwxr-xr-x 43 musa musa 4096 2013-08-02 14:56 ../ drwxr-xr-x 7 musa musa 4096 2013-08-02 14:57 .git/
Una volta che il repository è stato creato iniziamo ad aggiungere files al nostro progetto, aggiungiamo ad esempio un file di testo “file1.txt” che al suo interno abbia questo testo:
musa@amilo:~/mocambos$ echo 'hello world' > file.txt
git add . Aggiungerà ogni cosa cambiata.
musa@amilo:~/mocambos$ git add .
Facciamo il commit del nostro primo progetto Supponiamo che il nostro lavoro sia finito qui, siamo soddisfatti della frase scritta e vogliamo che diventi un punto fermo nella storia del nostro progetto: quello che vogliamo è creare un oggetto commit o come si dice in gergo “fare il commit del progetto”. Un commit è composto dai file che sono stati modificati dal precedente commit, un riferimento a tale commit e da un nome univoco. Se avete studiato un pò di teoria dei grafi potete immaginare i vari commit come un grafo aciclico e diretto:
- ciascun commit, escluso il primo, ha un riferimento ai precedenti commit (può essere figlio di due o più commit)
- ciascun commit, escluse le foglie, hanno un riferimento ai commit successivi.
Per creare il nostro primo commit digitiamo:
musa@amilo:~/mocambos$ git commit -a -m "initial commit"
Dovreste ottenere questo output:
musa@amilo:~/mocambos$ git commit -a -m "initial commit" [master (root-commit) 81a937a] initial commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 file.txt musa@amilo:~/mocambos$
Questa è la prima versione del progetto. in cui si vede chiaramente che abbiamo aggiunto un file. Creiamo altri due file sulla falsa riga del primo e creiamo un nuovo commit dopo aver creato ciascun file.
musa@amilo:~/mocambos$ echo 'hello world!' >file.txt musa@amilo:~/mocambos$ git commit -a -m "add emphasis" [master c03619d] add emphasis 1 files changed, 1 insertions(+), 1 deletions(-) musa@amilo:~/mocambos$
Dopo aver creato due commit digitiamo $git log vedremo un risultato simile al seguente:
musa@amilo:~/mocambos$ git log commit c03619ddb1c07958f6052ef96110dba6b27bb8b8 Author: Musa <musa jedo@exmple.org> Date: Fri Aug 2 15:24:18 2013 +0200 add emphasis commit 81a937a86dc0215999bb76f581e6e3a6d00d1aa9 Author: Musa <hamato_jedo@hotmail.com> Date: Fri Aug 2 15:18:02 2013 +0200 initial commit
Vediamo in ordine inverso i due oggetti commit che abbiamo creato, con tanto di nome univoco SHA1, l’autore la data ed il commento.
$git cat-file -t 64b2c91d $git ls-tree 64b2c91d $ git cat-file blob 64b2c91d $ find .git/objects/ $ find .git/objects/ $cat .git/refs/heads/master
Altri comandi molto utili sono:
* git status: mostra quali file sono cambiati tra lo stato attuale del progetto e lo stato corrente del repository (*) * git diff: mostra le differenze sui singoli files * git mv: marca un file come da spostare sul repository * git rm: marca un file come da rimuovere sul repository
(*) l’indicazione dello stato corrente necessita una spiegazione: all’interno del repository vengono mantenuti dei riferimenti ai diversi oggetti commit, il riferimento HEAD punta al commit corrente e viene portato avanti automaticamente quando si effettua un nuovo commit.
- Git Branches
I progetti non hanno mai una vita lineare, neanche nel mondo ideale. Ci sono sempre almeno un paio di versioni “funzionanti” nelle quali si prova ad aggiungere nuove funzionalità o rimuovere vecchi problemi. git tiene conto di queste esigenze e risponde con la funzionalità chiamata branch. In un repository possono coesistere più branch contemporaneamente, il primo viene creato di default e si chiama master tutti gli altri possono essere creati successivamente dall’utente. Per creare il nuovo branch 'develop' occorre digitare:
musa@amilo:~/mocambos$ git branch develop
in questo modo abbiamo creato un nuovo ramo. Possiamo vedere il risultato di questo comando digitando
musa@amilo:~/mocambos$ git branch
vedremo un risultato simile al seguente:
musa@amilo:~/mocambos$ git branch develop * master
l'asterisco indica il branch attualmente selezionato per passare da un branch all'altro
musa@amilo:~/mocambos$ git checkout master Already on 'master'
Per portare avanti il codice su develop, selezioniamo il branch develop
musa@amilo:~/mocambos$ git checkout develop Switched to branch 'develop'
Per iniziare a sviluppare sul nuovo branch dobbiamo digitare il comando:
musa@amilo:~/mocambos$ echo 'hello world again' >file.txt musa@amilo:~/mocambos$ git add . musa@amilo:~/mocambos$ git commit -a -m "add emphasis2" [develop 41afd11] add emphasis2 1 files changed, 1 insertions(+), 1 deletions(-)
Se guardiamo il log vediamo che non appare il tre commit, perché è stato effettuato sul branch master, mentre stiamo lavorando sul branch develop.
musa@amilo:~/mocambos$ git log commit 41afd11c0d0c0ae3008ad23b2565bc038a6c58ad Author: Musa <hamato_jedo@hotmail.com> Date: Fri Aug 2 15:45:13 2013 +0200 add emphasis2 commit c03619ddb1c07958f6052ef96110dba6b27bb8b8 Author: Musa <hamato_jedo@hotmail.com> Date: Fri Aug 2 15:24:18 2013 +0200 add emphasis commit 81a937a86dc0215999bb76f581e6e3a6d00d1aa9 Author: Musa <hamato_jedo@hotmail.com> Date: Fri Aug 2 15:18:02 2013 +0200 initial commit
Per avere una idea grafica di quello che sta succedendo possiamo usare questo comando (trovato su stackoverflow):
musa@amilo:~/mocambos$ git log --graph --date-order -C -M --pretty=format:" %ad [%an] %Cgreen%d%Creset %s" --all --date=short * 2013-08-02 [Musa] (HEAD, develop) add emphasis2 * 2013-08-02 [Musa] (master) add emphasis * 2013-08-02 [Musa] initial commit
Da notare che il nuovo oggetto commit ottenuto con il merge ha due genitori, il quarto commit del brach master ed il quinto commit del branch nuovo_ramo. Per saltare da un ramo ad un altro si usa il comando:
$ git checkout master
- Merge
Terminate le modifiche effettuate sul branch nuovo_ramo è adesso il momento riportarle sul branch master. Purtroppo non abbiamo garanzia che nessuno abbia intanto modificato i file del branch master, anzi, in uno sviluppo condiviso, questa è la norma, quindi incrociamo le dita e speriamo che non ci siano conflitti di sorta. Switchiamo sul branch master e digitiamo:
musa@amilo:~/mocambos$ git checkout master Switched to branch 'master' musa@amilo:~/mocambos$ git merge develop Updating c03619d..41afd11 Fast-forward file.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
will commit the result of the merge. Finally,
musa@amilo:~/mocambos$ gitk
se un giorno decidessimo che il branch develop non ci serve più, cancelliamolo
$git branch -d develop
- Eliminare un ramo
Dopo aver usato un ramo e dopo aver fatto il merge nel ramo principale possiamo decidere di eliminarlo dal nostro repository.
$ git branch -d <nome_ramo_locale> $ git branch -d -r <nome_ramo_remoto>
Questa prima parte della guida all’uso di git termina qui, nella prossima puntata affronteremo la condivisione dello stesso progetto su più utenti, anche attraverso internet.
- Prossimo Utilizzando git per la collaborazione
Git-annex
git-annex/ git-annex è grande. Si tratta di una estensione a git che permette di gestire i file con git senza peraltro riuscire a check-in git-annex fa sostituendo ogni file con un link simbolico che punta al reale contenuto nella directory git / annex (dal nome di un checksum del file di contenuti). Solo il collegamento simbolico viene controllato in git. ecco come fare per arrivare dal nulla per il monitoraggio di un file con git-annex:
- Creazione di un repository
Basta dire che una descrizione del repository.
musa@amilo:~$ mkdir Bocs musa@amilo:~$ cd Bocs/ musa@amilo:~/Bocs$ git init Initialized empty Git repository in /home/musa/Bocs/.git/ musa@amilo:~/Bocs$ git annex init "amilo" init amilo ok (Recording state in git...)
- aggiungere un remoto:
Come qualsiasi altro repository git, git-annex repository hanno remoto. Cominciamo con l'aggiunta di un drive USB come un remoto. se il tuo drive usb non installato, può installarlo con il commando sudo/mount/media/nome usb drive.
musa@amilo:/$sudo mount /media/6FFE-842D
per spostarlo nel usb drive con il commando cd /media/nome usb drive
musa@amilo:/$cd /media/6FFE-842D
clonare nostro directory con comando git clone ~/Bocs
musa@amilo:/media/6FFE-842D$ git clone ~/Bocs Initialized empty Git repository in /media/6FFE-842D/Bocs/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout.
spostare nel directory Bocs
musa@amilo:/media/6FFE-842D$cd Bocs musa@amilo:/media/6FFE-842D/Bocs$ git annex init "portable USB drive" init portable USB drive Detected a crippled filesystem. Enabling direct mode. Detected a filesystem without fifo support. Disabling ssh connection caching. ok (Recording state in git...)
per aggiunger usb drive remoto con computer portatile amilo
musa@amilo:/media/6FFE-842D/Bocs$ git remote add amilo ~/Bocs
aggiungere computer portatile amilo remoto con il drive USB
musa@amilo:/media/6FFE-842D/Bocs$ cd ~/Bocs musa@amilo:~/Bocs$ git remote add usbdrive /media/6FFE-842D/Bocs
Tutto questo è la configurazione standard di repository ad hoc distribuito git. L'unica git-annex specifica parte sta dicendo che il nome del nuovo repository creato sul drive USB. Si noti che entrambi i pronti contro termine sono impostati come remoto l'uno dell'altro. Ciò consente di ottenere sia annex file dall'altro. Avrai voglia di farlo, anche se si sta usando git in modo più centralizzato.
- aggiuntiamo un file nel directory Bocs al computer portatile amilo:
musa@amilo:~/Bocs$ cp /home/musa/zaghawa.jpg zaghawa.jpg musa@amilo:~/Bocs$ git annex add . add zaghawa.jpg (checksum...) ok (Recording state in git...) musa@amilo:~/Bocs$ git commit -a -m added [master (root-commit) d94ecb8] added 1 files changed, 1 insertions(+), 0 deletions(-) create mode 120000 zaghawa.jpg
Quando si aggiunge un file alla annex e commit, solo un link simbolico per il contenuto annex si impegna. Il contenuto stesso è memorizzato nel backend git-annex.
- ottenere il contenuto del file:
Un repository non ha sempre tutto il contenuto del file annex disponibile. Quando è necessario il contenuto di un file, è possibile usare "git annex ottenere" per renderlo disponibile. Possiamo usare questo per copiare tutto nella dependance del computer portatile per il drive USB.
musa@amilo:/media/6FFE-842D/Bocs$ git fetch amilo; git merge amilo/master remote: Counting objects: 9, done. remote: Compressing objects: 100% (6/6), done. remote: Total 8 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (8/8), done. From /home/musa/Bocs * [new branch] git-annex -> amilo/git-annex * [new branch] master -> amilo/master musa@amilo:/media/6FFE-842D/Bocs$ git annex get . get zaghawa.jpg (merging amilo/git-annex origin/git-annex into git-annex...) (Recording state in git...) (from amilo...) SHA256E-s56356--f4012fc17b574a5935e95219e9ec783deb401a70619c4c336c6dc71d0785b8a7.jpg 56356 100% 11.25MB/s 0:00:00 (xfer#1, to-check=0/1)
sent 56508 bytes received 31 bytes 113078.00 bytes/sec total size is 56356 speedup is 1.00 ok (Recording state in git...)
- sincronizzazione:-
Si noti che nell'esempio precedente, si doveva git fetch e unire dal computer portatile prima. Ciò consente git-annex sapere cosa è cambiato nel computer portatile, e quindi conosce i file lì presenti e possono farli.
musa@amilo:/media/6FFE-842D/Bocs$ git annex sync add zaghawa.jpg (checksum...) ok (Recording state in git...) commit (Recording state in git...) ok pull origin From /home/musa/Bocs e0231e2..44f655e git-annex -> origin/git-annex * [new branch] master -> origin/master ok pull amilo ok push origin Counting objects: 32, done. Delta compression using up to 2 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (24/24), 2.17 KiB, done. Total 24 (delta 3), reused 0 (delta 0) Unpacking objects: 100% (24/24), done. To /home/musa/Bocs * [new branch] git-annex -> synced/git-annex * [new branch] master -> synced/master ok push amilo Everything up-to-date ok
Dopo l'esecuzione di sincronizzazione, il repository sarà aggiornato con tutte le modifiche apportate ai propri remoto, ed eventuali cambiamenti nel repository sarà spinto fuori per i suoi remoti, dove una sincronizzazione li porterà. Ciò è particolarmente utile quando si usa git in modo distribuito, senza un repository nudo centrale. Vedere sincronizzazione per i dettagli. Si noti che la sincronizzazione sincronizza solo i metadati sui file che è memorizzato in git. Non sincronizzare il contenuto dei file, che sono gestiti da git-annex.
- usando ssh remoto:
Finora in questa procedura dettagliata, git-annex è stato utilizzato con un repository remoto su un drive USB. Ma può essere utilizzato anche con un remoto git che è veramente remota, un host accessibile da ssh. Diciamo che avete un desktop sulla stessa rete del computer portatile e vuole clonare annex del portatile ad esso:
$git clone ssh://mio portable/home/musa/Bocs $cd ~/Bocs $git annex init "mio Scrivania"
Ora è possibile ottenere i file e saranno trasferiti (usando rsync via ssh):
$git annex get zaghawa.jpg get my_cool_big_file (getting UUID for origin...) (from origin...) SHA256E-s56356--f4012fc17b574a5935e95219e9ec783deb401a70619c4c336c6dc71d0785b8a7.jpg 100% 2159 2.1KB/s 00:00 ok
Quando si elimina file, git-annex volontà ssh verso il remoto e assicurarsi che il contenuto del file è ancora lì prima di rimuoverla a livello locale:
git annex drop zaghawa drop zaghawa.jpg (checking origin..) ok
- spostamento del contenuto di file tra i repository:
Spesso si vuole spostare alcuni contenuti dei file da un archivio ad un altro uno. Ad esempio, rigido del computer portatile è sempre pieno, il tempo di spostare alcuni file su un disco esterno prima di passare un altro file da un file server al vostro computer portatile. Farlo a mano (usando git annex ottenere e git annex calo) è possibile, ma un po 'di dolore. git annex mossa rende molto facile.
musa@amilo:~/Bocs$ git annex move zaghawa.jpg --to usbdrive
- utilizzando tag e rami:
Come git, git-annex si blocca su ogni versione di un file (di default), in modo da poter rendere i tag e rami, e può controllare fuori in seguito a guardare i vecchi file.
musa@amilo:/media/6FFE-842D/Bocs$ git tag 1.0 musa@amilo:/media/6FFE-842D/Bocs$ rm -f zaghawa.jpg musa@amilo:/media/6FFE-842D/Bocs$ git commit -m deleted # On branch master # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # deleted: zaghawa.jpg # no changes added to commit (use "git add" and/or "git commit -a") musa@amilo:/media/6FFE-842D/Bocs$ git checkout 1.0 D zaghawa.jpg Note: checking out '1.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at d18d244... git-annex automatic sync
Naturalmente, quando si git checkout un vecchio ramo, alcune vecchie versioni di file potrebbero non essere disponibili a livello locale, e possono essere memorizzate in qualche altro repository. È possibile utilizzare git annex arrivare a farli come al solito.
- gestire automaticamente il contenuto:
Una volta che si dispone di più repository, e forse avete configurato numcopies, ogni file può avere molte più copie del necessario, o forse meno di quanto avrebbe voluto. Come gestire questo? Il whereis sottocomando può essere usato per vedere quante copie di un file sono noti, ma poi si deve decidere cosa prendere o cadere. In questo esempio, non vi sono forse abbastanza copie del primo file, e troppi del secondo file.
$cd /media/6FFE-842D/ $git annex whereis whereis zaghawa.jgp (2 copies) 0c443de8-e644-11df-acbf-f7cd7ca6210d -- amilo 62b39bbe-4149-11e0-af01-bb89245a1e61 -- here (usb drive)