Utilisation de Git et GitLab

From devSpot-wikis
(Difference between revisions)
Jump to: navigation, search
(Pourles utilisateurs Windows)
(Pourles utilisateurs Windows)
Line 77: Line 77:
   
 
[[File:git_cle_ssh.png]]
 
[[File:git_cle_ssh.png]]
  +
 
* '''Installation de TortoiseGit''':
 
* '''Installation de TortoiseGit''':
 
Ajoute les commandes GIT, de manière graphique, dans l'environnement de l'explorer de Windows. Suivre les indications d'installation du programme.
 
Ajoute les commandes GIT, de manière graphique, dans l'environnement de l'explorer de Windows. Suivre les indications d'installation du programme.
Line 84: Line 85:
   
 
[[File:git_for_windows_install.png]]
 
[[File:git_for_windows_install.png]]
  +
 
La deuxième option utile est de convertir les caractères « retour à la ligne » de windows en système UNIX :
 
La deuxième option utile est de convertir les caractères « retour à la ligne » de windows en système UNIX :
   
 
[[File:git_for_windows_install2.png]]
 
[[File:git_for_windows_install2.png]]
  +
  +
* '''Utilisation de TortoiseGit''':
  +
** Cloner un repository:

Revision as of 09:19, 13 February 2015

Contents

Références

Mémo d'utilisation de Git

Travailler avec Git en local

  • Initialisation d'un dépôt :

dans le répertoire existant du logiciel taper :

 git init
  • Ajouter des fichiers pour suivre leur version :

taper

 git add nom-du-fichier 

puis

 git commit -m 'version initiale du projet'

git add permet d'ajouter (indexer) les fichiers au projets (possible d'ajouter tout avec git add *).
git commit permet d'enregistrer (valider) les modifications (l'option –amend permet d'annuler le commit).
ATTENTION : toujours inspecter les modifications pour savoir si tout est bien indexé en tapant la commande git status.

  • Se définir un patron de travail :

renseigner un fichier .gitignore pour éviter d'indexer ou de valider ce qu'on ne veut pas, exemple :

 # un commentaire, cette ligne est ignorée
 # pas de fichier .a
 *.a
 # mais suivre lib.a malgré la règle précédente
 !lib.a
 # ignorer uniquement le fichier TODO à la racine du projet
 /TODO
 # ignorer tous les fichiers dans le répertoire build
 build/
 # ignorer doc/notes.txt, mais pas doc/server/arch.txt
 doc/*.txt
 # ignorer tous les fichiers .txt sous le répertoire doc/
 doc/**/*.txt

Autres exemples sur [1]. Penser aux fichiers *~ et *.lock.

  • Supprimer ou déplacer un fichier :
 git rm nom-du-fichier
 git mv nom-du-fichier

Les fichiers indexés qui feront parties de la prochaine validation :

 git diff --staged
  • Obtenir des infos sur la version actuelle du projet :
 git log 

(git log -p -2 permet de voir les différences avec les 2 commits précédents)

  • Lister et créer des étiquettes pour les versions stables :
 git tag pour lister les étiquettes.
 git tag -a v1.4.0 -m 'Version 1.4.0' pour ajouter une étiquette au dernier commit.

Rappel – règles pour les étiquettes : vA.B.C avec A=version majeure, B=version mineure, C=correctif On commence la numérotation à 0. On réserve A=0 pour le protoype, A=1 est la première version stable.

Travailler avec un dépôt distant et GitLab

  • Création d'un dépôt :

Se rendre sur l'interface Gitlab sur le serveur devspot et créer le dépôt à partir de l'interface graphique. Récupérer un dépôt distant en local pour la première fois (clone) :

 git clone http://adresse/nom_du_depot_distant  nom_du_dossier_local

Attention : ne pas oublier que le nom du dépôt distant se termine par .git. On peut récupérer l'URL exacte dans la page « Activity » du projet.

  • Récupérer et fusionner la branche principale (master) du dépôt distant avec celle créée localement lors d'un clonage :
 git pull
  • Pousser la branche master locale vers le serveur depuis lequel vous avez cloné le dépôt (origin) :
 git push origin master

ou sinon plus générique

 git push [nom-distant] [nom-de-branche-locale] 

Attention : si quelqu'un a poussé entre temps on aura un message de rejet, on doit d'abord tirer les modifications de la personne précédente, les fusionner avec les votres et pousser.


Pourles utilisateurs Windows

  • Ajouter sa clé SSH à GitLab:

Utiliser l'outil puttyGen pour générer une paire de clés privées/publiques. Si vous avez déjà une paire de clés, l'ouvrir via puttyGen et récupérer la clé publique (car ATTENTION : copié/collé depuis le bloc-note ne fonctionne pas).

Git cle ssh.png

  • Installation de TortoiseGit:

Ajoute les commandes GIT, de manière graphique, dans l'environnement de l'explorer de Windows. Suivre les indications d'installation du programme.

  • Installation de "Git for windows":

Lors de l'installation, 2 options peuvent être utiles. La première (ci-dessous) rend les commandes UNIX et Git utilisables depuis ms-dos.

Git for windows install.png

La deuxième option utile est de convertir les caractères « retour à la ligne » de windows en système UNIX :

Git for windows install2.png

  • Utilisation de TortoiseGit:
    • Cloner un repository:
Personal tools
Namespaces

Variants
Actions
Navigation
Campagnes de l'OPAR
Projets
Developpements
Support informatique
Tools