Difference between revisions of "Git"
DavideTateo (Talk | contribs) (→Comandi utili) |
DavideTateo (Talk | contribs) (→Clonare un repository con submodules) |
||
| (21 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | = Concetti Fondamentali = | ||
| + | |||
| + | Git è un [http://it.wikipedia.org/wiki/Controllo_versione sistema di controllo versione] distribuito. | ||
| + | Questo vuol dire che ogni copia locale è un repository a se stante. Quindi a differenza di SVN la gestione dei repository è più complessa, con il vantaggio di una maggiore versatilità. | ||
| + | Avere un repository locale significa che è possibile committare in locale il proprio lavoro. Una volta committato in locale il proprio lavoro si può sincronizzare il repository locale con quello remoto. Si chiama pull l'operazione che aggiorna il repository locale con quello remoto. Si chiama push l'operazione che invia i commit locali sul repository remoto. | ||
| + | Per poter eseguire correttamente un push, è necessario che l'ultimo commit locale e l'ultimo commit remoto siano lo stesso, il che significa che per effettuare un push, è necessario, a meno di non aver il repository locale già aggiornato, effettuare un pull. | ||
| + | |||
| + | Il repository locale mantiene la storia locale dei commit. Tuttavia è possibile effettuare modifiche sul repository locale. Per aggiungere a un commit modifiche locali e nuovi file, è necessario aggiungere i file (sia quelli nuovi, sia quelli modificati) all'indice del repository. Ogni volta che si effettua un commit verranno considerati solo i file presenti nell'indice, tutte le altre modifiche locali non verranno aggiunte al commit, ma resteranno nel repository. | ||
| + | |||
| + | Può capitare, se più persone lavorano a un progetto, che la copia sul repository remoto abbia subito modifiche rispetto all'ultimo commit del repository locale, ovvero che le due versioni (locale e remoto) abbiano un antenato in comune, ma poi si siano divise. In questo caso è necessario effettuare un merge. Se i due rami non hanno modifiche conflittuali, il merge sarà automatico. Se i due rami presentano delle modifiche concorrrenti, o modifiche che git non è in grado di risolvere (ad esempio cambio intentazione e spaziatura differenti) si dovrà procedere a un merge manuale. | ||
| + | In caso di versioni discordanti è necessario ricordarsi di procedere nelseguente modo: | ||
| + | * effettuare il commit del proprio lavoro | ||
| + | * effettuare il pull del repository remoto | ||
| + | * effettuare il merge | ||
| + | * effettuare il push del repository | ||
| + | |||
| + | Che sia un merge automatico o un merge manuale, l'operazione si conclude sempre con un commit. | ||
| + | |||
= Guida base git= | = Guida base git= | ||
Segue una piccola guida minimale per utilizzare git in maniera semplice. | Segue una piccola guida minimale per utilizzare git in maniera semplice. | ||
| − | per imparare a usarlo in maniera avanzata consigliamo di cercare | + | per imparare a usarlo in maniera avanzata consigliamo di cercare tutorial su internet. |
| + | Questa guida non ha la pretesa quindi di spiegare l'effettivo funzionamento, ma solo di riuscire a utilizzare il repository in maniera base. | ||
== creazione repository git == | == creazione repository git == | ||
| − | |||
| − | |||
| − | |||
una volta creato il repository sul vostro server, o su un provider esterno (github, assembla, bitbucket) | una volta creato il repository sul vostro server, o su un provider esterno (github, assembla, bitbucket) | ||
| − | + | git clone git@server:/var/git/repo_name local_repo_name | |
| + | |||
| + | Il repository git ufficiale dell'airlab è [https://github.com/AIRLab-POLIMI qui], potete chiedere al professor [[User:AndreaBonarini | Bonarini]] di farvi creare un repository per il vostro progetto. | ||
| + | |||
| + | == Impostazioni globali == | ||
| + | Prima di fare il primo commit è importante impostare email e nome utente nel seguente modo: | ||
| + | |||
| + | git config --global user.email ''email'' | ||
| + | |||
| + | git config --global user.name ''username'' | ||
| + | |||
| + | |||
| + | ''email'' è la vostra e-mail | ||
| + | ''username'' è il vostro username | ||
| + | |||
| + | E' importante avere impostato correttamente questi campi, anche perchè sono utilizzati, specialmente la mail, dalle interfacce grafiche dei servizi di hosting (vedasi github) per riconoscere gli utenti. | ||
== primo commit == | == primo commit == | ||
| Line 19: | Line 50: | ||
git add -A | git add -A | ||
| − | |||
| − | |||
| − | |||
| − | |||
git commit | git commit | ||
| Line 33: | Line 60: | ||
| − | = successivi commit = | + | == successivi commit == |
git add -A | git add -A | ||
| Line 44: | Line 71: | ||
git pull | git pull | ||
| − | |||
| − | = | + | = Guida ai submodules = |
| − | == | + | == Clonare un repository con submodules == |
| − | + | per clonare un repository che contiene submodules,usare il comando | |
| − | |||
| − | + | git clone git@server:/var/git/repo_name local_repo_name --recursive | |
| − | |||
| − | + | in alternativa, se il clone è stato effettuato senza il flag --recursive è possibile usare | |
| − | |||
| − | == | + | git submodule init |
| + | |||
| + | git submodule update | ||
| + | |||
| + | == aggiornare i submodule == | ||
| + | |||
| + | Per aggiornare i submodule è possibile utilizzare il comando: | ||
| + | |||
| + | git submodule update --remote | ||
| + | |||
| + | = Comandi utili = | ||
| − | + | * status | |
| + | * pull | ||
| + | * push | ||
| + | * commit | ||
| + | * add | ||
| + | * rm | ||
| + | * stash | ||
| + | * checkout | ||
| + | * revert | ||
| + | * reset | ||
| + | * rebase | ||
| + | * mergetool | ||
Latest revision as of 18:13, 8 June 2017
Contents
Concetti Fondamentali
Git è un sistema di controllo versione distribuito. Questo vuol dire che ogni copia locale è un repository a se stante. Quindi a differenza di SVN la gestione dei repository è più complessa, con il vantaggio di una maggiore versatilità. Avere un repository locale significa che è possibile committare in locale il proprio lavoro. Una volta committato in locale il proprio lavoro si può sincronizzare il repository locale con quello remoto. Si chiama pull l'operazione che aggiorna il repository locale con quello remoto. Si chiama push l'operazione che invia i commit locali sul repository remoto. Per poter eseguire correttamente un push, è necessario che l'ultimo commit locale e l'ultimo commit remoto siano lo stesso, il che significa che per effettuare un push, è necessario, a meno di non aver il repository locale già aggiornato, effettuare un pull.
Il repository locale mantiene la storia locale dei commit. Tuttavia è possibile effettuare modifiche sul repository locale. Per aggiungere a un commit modifiche locali e nuovi file, è necessario aggiungere i file (sia quelli nuovi, sia quelli modificati) all'indice del repository. Ogni volta che si effettua un commit verranno considerati solo i file presenti nell'indice, tutte le altre modifiche locali non verranno aggiunte al commit, ma resteranno nel repository.
Può capitare, se più persone lavorano a un progetto, che la copia sul repository remoto abbia subito modifiche rispetto all'ultimo commit del repository locale, ovvero che le due versioni (locale e remoto) abbiano un antenato in comune, ma poi si siano divise. In questo caso è necessario effettuare un merge. Se i due rami non hanno modifiche conflittuali, il merge sarà automatico. Se i due rami presentano delle modifiche concorrrenti, o modifiche che git non è in grado di risolvere (ad esempio cambio intentazione e spaziatura differenti) si dovrà procedere a un merge manuale. In caso di versioni discordanti è necessario ricordarsi di procedere nelseguente modo:
- effettuare il commit del proprio lavoro
- effettuare il pull del repository remoto
- effettuare il merge
- effettuare il push del repository
Che sia un merge automatico o un merge manuale, l'operazione si conclude sempre con un commit.
Guida base git
Segue una piccola guida minimale per utilizzare git in maniera semplice. per imparare a usarlo in maniera avanzata consigliamo di cercare tutorial su internet. Questa guida non ha la pretesa quindi di spiegare l'effettivo funzionamento, ma solo di riuscire a utilizzare il repository in maniera base.
creazione repository git
una volta creato il repository sul vostro server, o su un provider esterno (github, assembla, bitbucket)
git clone git@server:/var/git/repo_name local_repo_name
Il repository git ufficiale dell'airlab è qui, potete chiedere al professor Bonarini di farvi creare un repository per il vostro progetto.
Impostazioni globali
Prima di fare il primo commit è importante impostare email e nome utente nel seguente modo:
git config --global user.email email
git config --global user.name username
email è la vostra e-mail
username è il vostro username
E' importante avere impostato correttamente questi campi, anche perchè sono utilizzati, specialmente la mail, dalle interfacce grafiche dei servizi di hosting (vedasi github) per riconoscere gli utenti.
primo commit
cd local_repo_name
crei dei file da committare
git add -A
git commit
git push origin master
primo pull
cd local_repo_name git pull origin master
successivi commit
git add -A
git commit
git push
successivi pull
git pull
Guida ai submodules
Clonare un repository con submodules
per clonare un repository che contiene submodules,usare il comando
git clone git@server:/var/git/repo_name local_repo_name --recursive
in alternativa, se il clone è stato effettuato senza il flag --recursive è possibile usare
git submodule init
git submodule update
aggiornare i submodule
Per aggiornare i submodule è possibile utilizzare il comando:
git submodule update --remote
Comandi utili
- status
- pull
- push
- commit
- add
- rm
- stash
- checkout
- revert
- reset
- rebase
- mergetool
