Récupérer un dépôt Git:
$ git clone URL
Pour mettre à jour la copie locale d'un dépôt déjà cloné :
$ git pull origin master
Avant de faire des commits :
git config --global user.name "Vos Nom/Prénom" git config --global user.email "votre.email@hadoly.fr"
Pour commiter et pousser vers le dépôt :
$ git add FICHIER(S) # -> ceux qu'on veut commiter qu'ils soient nouveaux ou simplement modifiés $ git commit -m "mon message de commit" # -> modifs prises en compte mais attention: le commit est local ! $ git pull --rebase origin master # -> pas obligatoire mais conseillé si des modifs ont été faites sur le dépôt $ git push origin master # -> pousse vers le dépôt mais attention il faut avoir les droits !
Pour connaître l'état actuel :
$ git diff # -> pour voir les modifications $ git status # -> liste les fichiers modifiés, non suivis, ajoutés,...
Et connaître l'historique :
$ git log # éventuellement l'option -p permet d'afficher les diff
Git est un logiciel libre de système de gestion de version (Version Control System), créé initialement en 2005 par Linus Torval pour gérer le développement du noyau Linux.
Il s'agit sans aucun doute du système de gestion de version le plus populaire de nos jours (utilisé par plus de 12 millions de personnes).
À la différence de SVN, Git est un système dit décentralisé ne nécessitant pas un serveur central afin de travailler.
Ainsi la gestion de version s'effectue en local et peut être synchronisée avec un ou plusieurs dépôts. Il est possible de définir un dépôt principal avant envoi vers un dépôt à l'instar d'un système centralisé.
De par le fonctionnement en local, il diffère dans son utilisation d'un système type SVN, aussi les utilisateurs de tels systèmes devront être particulièrement vigilant.
Le travail s'effectue en local, par conséquent les commits sont locaux contrairement à SVN.
Les commits peuvent être arrangés (fusion, suppression, modification de message de commit, d'auteur…) avant synchronisation avec un dépôt.
Git permet une utilisation facilité du principe de branches.
Ceci permet la mise en pratique de bonnes manières de gestion des sources en séparant par exemple les branches stables, développement, livraison, gestion de nouvelle fonctionnalité, bugs,…
La fusion est connue pour être bien gérée par Git lorsque plusieurs personnes travaille sur les mêmes fichiers.
Ainsi un tag est une simple étiquette renvoyant à un numéro de commit particulier.
Une nouvelle branche part du même lieu que la branche depuis laquelle elle est extraite et ne duplique aucune donnée. Puis seul les diff avec les commits précédents sont enregistrés.
Il faut être très vigilant avec le commit !
En effet l'auteur d'un commit sont également fournies est identifié par un auteur et une adresse email.
Ces informations sont renseignées automatiquement lors d'un commit.
Elles doivent donc être configurées avec minutie sachant qu'il y a deux niveaux de configuration dans l'ordre des priorités suivant :
Synchronisation avec le serveur :
Dans le dossier d'un projet, le dossier .git intègre la configuration locale dans le fichier config. Cependant ce fichier ne devrait pas être modifié manuellement mais de préférence par la commande git config.
La configuration globale est valable pour tout projet Git si une configuration locale ne la surcharge pas.
Pour configurer globalement vos informations de commit :
git config --global user.name "Vos Nom/Prénom" git config --global user.email "votre.email@hadoly.fr"
Il est important de noter que le commit ne se fait pas comme avec SVN.
En effet un commit est une opération s'effectuant sur des fichiers au préalable sélectionné par le stagging.
En d'autres termes, il faut désigner les fichiers à commité avant de les commiter.
Ceci se fait avec la commande git add qui est par conséquent un faux ami de SVN car sur ce dernier, add permet d'ajouter un nouveau fichier.
Donc pour commiter les modifications d'un fichier (ou en ajouter un nouveau) avec Git, il faut faire git add FICHIER(S) puis git commit systématiquement comme suit :
git add fichier_modifié git commit -m "description du commit"
Note: souvenez vous que ce le commit est local, rien n'est envoyé au serveur !
Le travail s'effectuant en local, lorsqu'un commit est fait il n'est pas synchronisé avec le dépôt principal contrairement à un commit SVN. Tant que l'envoi vers le serveur n'a pas été fait (push), tout le travail commité n'est pas présent sur le serveur ! Ainsi un cycle complet du commit à la synchronisation au serveur se fait comme suit :
git add fichier_modifié git commit -m "description du commit" git push origin master
Comme évoqué, à la première utilisation de Git sur votre machine, vous devez indiquer vos nom et adresse email qui serviront aux commits.
La configuration est stockée dans des fichiers de configuration au format INI.
Trois niveaux de configurations sont disponibles : système, global et local.
Les fichiers correspondants sont respectivement /etc/gitconfig, ~/.gitconfig et .git/config du dossier racine d'un dépôt local.
Le commande permettant de gérer la configuration automatiquement est git config (elle opère sur les fichiers adéquats).
Les options --system, --global et --local permettent à git config d'opérer spécifiquement à un niveau particulier.
Pour connaître la configuration actuelle (local + global + système) :
git config --list
Notez que la configuration locale s'applique à un projet et se définit dans un dossier appartenant à l'arborescence du projet en utilisant comme mentionné l'option --local.
git config [option] <PARAMETER> <VALUE>
La commande git clone URL permet de récupérer un projet géré par Git. Il faut indiquer l'adresse du dépôt contenant le projet. Par exemple :
git clone ssh://doc@wiki.hadoly.fr/srv/doc/doc.git
Ceci va récupérer le projet dans le dossier test_project du dossier courant.
Par défaut ce dépôt distant sera identifié par le nom origin.
Pour créer un projet Git local, il suffit de se placer dans le dossier du projet et de lancer :
git init
Pour connaître l'état actuel du projet et donc savoir s'il y a des fichiers modifiés, il faut utiliser :
git status
Le résultat indique les fichiers modifiés/supprimés/non suivis/… et les commandes à exécuter pour effectuer les différentes opérations nécessaires.
Pour connaître la liste des modifications (commits) il faut utiliser git log :
git log
Afin de voir les modifications de chaque commit il faut utiliser l'option -p :
git log -p
Il est possible de préciser un certains nombre de commits après un tiret -. Par exemple, pour avoir les 2 derniers commits:
git log -p -2
Pour commiter un fichier modifié (ou ajouter un nouveau fichier) :
git add FICHIER_MODIFIÉ_OU_NOUVEAU ... git commit -m "description du commit"
Attention : ceci rajoute la modification en local, l'éventuel serveur distant n'est pas informé, il faut utiliser git push pour envoyer la modification.
L'option -m permet d'indiquer un message de commit. Ce dernier est obligatoire.
Si l'option -m n'est pas fournie, un éditeur de texte sera ouvert pour vous demander le message de commit. Les lignes commençant par le caractère # sont ignorées.
Pour récupérer les modifications éventuelles de la branche master du dépôt distant identifié par origin:
git pull origin master
Notez que si vous avez des modifications locales commitées mais pas encore envoyées au serveur, il est nécessaire d'indiquer à Git de synchroniser les historiques :
git pull --rebase origin master
En pratique c'est cette dernière commande qui devrait toujours être utilisée pour mettre à jour la copie locale.
Pour pousser les modifications commitées localement vers la branche master du dépôt distant identifié par origin, il faut faire :
git push origin master
Notez qu'il est fortement recommandé de mettre à jour en premier la copie locale avec la commande vue précédemment avant de pousser :
git pull --rebase origin master git push origin master
Voici un tableau récapitulant les différentes commandes SVN et leur équivalent Git.
| SVN | GIT |
|---|---|
| svnadmin create | git init [–bare] |
| svn status | git status |
| svn checkout | git clone |
| svn update | git pull |
| svn add | git add |
| svn commit | git add |
| + git commit | |
| + git push | |
| svn rm/mv/diff/log/blame | git rm/mv/diff/log/blame |
TortoiseGit est un logiciel libre pour Windows permettant de manipuler Git via le navigateur de fichiers.
Il s'agit de l'équivalent de TortoiseSvn mais pour Git.
Le logiciel modifie les icônes du navigateur de fichier ainsi que le menu accessible par un clic droit.
Les éléments (fichiers / dossiers) du navigateur d'un dossier suivi par Git se voient attribuer une petite icône supplémentaire indiquant l'état de l'élément (point d'exclamation rouge pour un élément modifié commité, point d'interrogation bleu pour élément non suivi, marque verte pour élément commité, croix bleue pour élément ajouté non commité,…).
L'installeur de TortoiseGit peut être téléchargé à l'adresse suivante : https://tortoisegit.org/download/
La configuration est accessible dans le menu Settings accessible par un clic droit dans le navigateur de fichier.
Comme déjà mentionné, il est impératif à la première utilisation de TortoiseGit de configurer au minimum le nom et le email de l'utilisateur (utilisés pour les commits). Ceci peut se faire dans le navigateur de fichier dans le menu : <html><clic droit></html>→Settings→Git→User Info Name/Email
RabbitVCS est un gestionnaire graphique de gestion de version pour Git et SVN semblable à Trotoise sous Windows. Il est destiné aux navigateurs de fichiers Nautilus et Thunar, et à l'éditeur Gedit.
Vous pouvez vérifier si rabbitvcs est dans les dépôts de votre système pour l'installer sinon, sur Ubuntu, un PPA fournit une version pré-compilée.
Vous pouvez sinon le télécharger à l'adresse http://wiki.rabbitvcs.org/wiki/download.
Si vous avez le gestionnaire de bureau Unity ou Gnome Shell, il vous faudra une version particulière pour nautilus : rabbitvcs-nautilus3.
Ce que l'on nomme ici un dépôt principal est un dépôt depuis lequel on peut cloner un projet ou vers lequel pousser des modifications.
Un tel dépôt peut être présenté sous différentes formes: un dossier, un fichier, un serveur web.
Il peut être accédé directement (dossier, fichier) ou à distance via différents protocoles (GIT, HTTP, HTTPS, SSH).
Pour créer un dépôt principal Git qui n'est pas un dépôt de travail, on parle d'un dépôt bare.
Un simple dossier initialisé avec git init --bare devient un dépôt principal qui peut être cloné et vers lequel on peut pousser.
Il est également possible de travailler avec un dépôt sous forme de fichier. Ce dernier s'appelle un bundle.
Il existe des serveurs qui permettent de créer/stocker des dépôts. Ceci peut être assimilé à un dépôt SVN.
Un tel serveur des plus connus est Github qui propose à ses utilisateurs d'héberger leurs dépôts et ce gratuitement pour les dépôt publics.
Par ailleurs Gitlab est un logiciel libre permettant de créer un serveur de dépôts avec interface web et grand nombre de fonctionnalités. Plus récent, Gogs est plus léger et ressemble énormément à Github.
De plus le site officiel propose à l'instar de Github de l'hébergement de dépôts à ses utilisateur dans des conditions similaires.
En français :