Pro Git

Le protocole de base est le protocole local pour lequel le dépôt distant est un autre répertoire dans le système de fichier. Il est souvent utilisé si tous les membres de l'équipe ont accès à un répertoire partagé via NFS par exemple ou dans le cas moins probable où tous les développeurs travaillent sur le même ordinateur. Ce dernier cas n'est pas optimum, car tous les dépôts seraient hébergés de fait sur le même ordinateur, rendant ainsi toute défaillance catastrophique.

Si vous disposez d'un système de fichiers partagé, vous pouvez cloner, pousser et tirer avec un dépôt local. Pour cloner un dépôt ou pour l'utiliser comme dépôt distant d'un projet existant, utilisez le chemin vers le dépôt comme URL. Par exemple, pour cloner un dépôt local, vous pouvez lancer ceci :

$ git clone /opt/git/projet.git

Ou bien cela :

$ git clone file:///opt/git/projet.git

Git opère légèrement différemment si vous spécifiez explicitement le protocole file:// au début de l'URL. Si vous spécifiez simplement le chemin, Git tente d'utiliser des liens durs ou une copie des fichiers nécessaires. Si vous spécifiez le protocole file://, Git lance un processus d'accès au travers du réseau, ce qui est généralement moins efficace. La raison d'utiliser spécifiquement le préfixe file:// est la volonté d'obtenir une copie propre du dépôt, sans aucune référence ou aucun objet supplémentaire qui pourraient résulter d'un import depuis un autre système de gestion de version ou d'une action similaire (voir chapitre 9 pour les tâches de maintenance). Nous utiliserons les chemins normaux par la suite, car c'est la méthode la plus efficace.

Pour ajouter un dépôt local à un projet Git existant, lancez ceci :

$ git remote add proj_local /opt/git/projet.git

Ensuite, vous pouvez pousser vers et tirer depuis ce dépôt distant de la même manière que vous le feriez pour un dépôt accessible sur le réseau.

IV-A-1-a. Avantages▲

IV-A-1-b. Inconvénients▲

Le protocole SSH est probablement le protocole de transport de Git le plus utilisé. Cela est dû au fait que l'accès SSH est déjà en place à de nombreux endroits et que si ce n'est pas le cas, cela reste très facile à faire. Cela est aussi dû au fait que SSH est le seul protocole permettant facilement de lire et d'écrire à distance. Les deux autres protocoles réseau (HTTP et Git) sont généralement en lecture seule et s'ils peuvent être utiles pour la publication, le protocole SSH est nécessaire pour les mises à jour de par ce qu'il permet l'écriture. SSH est un protocole authentifié suffisamment répandu et sa mise œuvre est simplifiée.

Pour cloner un dépôt Git à travers SSH, spécifiez le préfixe ssh:// dans l'URL comme ceci :

$ git clone ssh://utilisateur@serveur:projet.git

ou ne spécifiez pas de protocole du tout - Git choisit SSH par défaut si vous n'êtes pas explicite :

$ git clone utilisateur@serveur:projet.git

Vous pouvez aussi ne pas spécifier de nom d'utilisateur et Git utilisera par défaut le nom de login.

IV-A-2-a. Avantages▲

IV-A-2-b. Inconvénients▲

Vient ensuite le protocole Git. Celui-ci est géré par un daemon spécial livré avec Git. Ce démon écoute sur un port dédié (9418) et propose un service similaire au protocole SSH, mais sans aucune sécurisation. Pour qu'un dépôt soit publié via le protocole Git, le fichier git-export-daemon-ok doit exister, mais mise à part cette condition sans laquelle le daemon refuse de publier un projet, il n'y a aucune sécurité. Soit le dépôt Git est disponible sans restriction en lecture, soit il n'est pas publié. Cela signifie qu'il ne permet de pousser des modifications. Vous pouvez activer la capacité à pousser, mais étant donné l'absence d'authentification, n'importe qui sur Internet peut pousser sur le dépôt. Autant dire que ce mode est rarement recherché.

IV-A-3-a. Avantages▲

IV-A-3-b. Inconvénients▲

Enfin, il reste le protocole HTTP. La beauté de HTTP ou HTTPS tient dans la simplicité à le mettre en place. Tout ce qu'il y a à faire, c'est de simplement copier un dépôt Git nu sous votre racine de document HTTP et de paramétrer un crochet postupdate et c'est prêt (voir chapitre 7 pour les détails sur les crochets de Git). À partir de ceci, toute personne possédant un accès au serveur web sur lequel vous avez copié votre dépôt peut le cloner. Pour autoriser un accès en lecture à votre dépôt sur HTTP, faites ceci :

$ cd /var/www/htdocs/
$ git clone --bare /chemin/vers/git_projet projetgit.git
$ cd projetgit.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

C'est tout. Le crochet postupdate qui est livré avec Git par défaut lance la commande appropriée (git update-server-info) pour permettre un fonctionnement correct du clonage et de la récupération par HTTP. Cette commande est lancée lorsque vous poussez vers ce dépôt par SSH ; ainsi, les autres personnes peuvent cloner via la commande

$ git clone http://exemple.com/projetgit.git

Dans ce cas particulier, nous utilisons le chemin /var/www/htdocs qui est commun pour les installations d'Apache, mais vous pouvez utiliser n'importe quel serveur web de pages statiques - il suffit de placer le dépôt nu dans le chemin d'accès. Les données Git sont servies comme des simples fichiers statiques (voir chapitre 9 pour la manière détaillée dont ils sont servis).

Il est possible de faire pousser Git à travers HTTP, bien que cette technique ne soit pas utilisée et nécessite de gérer les exigences complexes de WebDAV. Comme elle est rarement utilisée, nous ne la détaillerons pas dans ce livre. Si vous êtes tout de même intéressé par l'utilisation des protocoles de push-HTTP, vous pouvez vous référer à http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt. Un des intérêts à permettre de pousser par HTTP est que vous pouvez utiliser sur n'importe quel serveur WebDAV, sans liaison avec Git. Il est donc possible d'utiliser cette fonctionnalité si votre fournisseur d'hébergement web supporte WebDAV pour la mise à jour de vos sites.

IV-A-4-a. Avantages▲

IV-A-4-b. Inconvénients▲

À présent que vous avez une copie nue de votre dépôt, il ne reste plus qu'à la placer sur un serveur et à régler les protocoles. Supposons que vous avez mis en place un serveur nommé git.exemple.com auquel vous avez accès par SSH et que vous souhaitez stocker vos dépôts Git dans le répertoire /opt/git. Vous pouvez mettre en place votre dépôt en copiant le dépôt nu :

$ scp -r mon_projet.git utilisateur@git.exemple.com:/opt/git

À partir de maintenant, tous les autres utilisateurs disposant d'un accès SSH au serveur et ayant un accès en lecture seule au répertoire /opt/git peuvent cloner votre dépôt en lançant la commande

$ git clone utilisateur@git.exemple.com:/opt/git/mon_projet.git

Si un utilisateur se connecte par SSH au serveur et a accès en lecture au répertoire /opt/git/mon_projet.git, il aura automatiquement accès pour tirer. Git ajoutera automatiquement les droits de groupe en écriture à un dépôt si vous lancez la commande git init avec l'option --shared.

$ ssh utilisateur@git.exemple.com
$ cd /opt/git/mon_projet.git
$ git init --bare --shared

Vous voyez comme il est simple de prendre un dépôt Git, créer une version nue et la placer sur un serveur auquel vous et vos collaborateurs avez accès en SSH. Vous voilà prêts à collaborer sur le même projet.

Il faut noter que c'est littéralement tout ce dont vous avez besoin pour démarrer un serveur Git utile auquel plusieurs personnes ont accès - ajoutez des comptes SSH sur un serveur, et collez un dépôt nu quelque part où tous les utilisateurs ont accès en lecture et écriture. Vous êtes prêts à travailler, vous n'avez besoin de rien d'autre.

Dans les chapitres à venir, nous traiterons de mises en place plus sophistiquées. Ces sujets incluront l'élimination du besoin de créer un compte système pour chaque utilisateur, l'accès public aux dépôts, la mise en place d'interfaces utilisateurs web, l'utilisation de l'outil Gitosis, etc. Néanmoins, gardez à l'esprit que pour collaborer avec quelques personnes sur un projet privé, tout ce qu'il faut, c'est un serveur SSH et un dépôt nu.

Si vous travaillez dans un petit groupe ou si vous n'êtes qu'en phase d'essai de Git au sein de votre société avec peu de développeurs, les choses peuvent rester simples. Un des aspects les plus compliqués de la mise en place d'un serveur Git est la gestion des utilisateurs. Si vous souhaitez que certains dépôts ne soient accessibles à certains utilisateurs qu'en lecture seule et en lecture/écriture pour d'autres, la gestion des accès et des permissions peut devenir difficile à régler.

IV-B-2-a. Accès SSH▲

L'installation de Gitolite est très simple, même sans lire la documentation extensive qui l'accompagne. Vous n'avez besoin que d'un compte sur un serveur de type Unix ; plusieurs distributions Linux et Solaris 10 sont compatibles. Vous n'avez pas besoin d'accès root si git, perl et un serveur compatible OpenSSH sont déjà installés. Dans les exemples ci-dessous, nous utiliserons le compte gitolite sur un hôte appelé gitserver

Par rapport au concept de logiciel serveur, Gitolite est plutôt inhabituel : l'accès se fait via ssh et donc tout utilisateur du système est potentiellement un « hôte Gitolite ». De ce fait, il n'y a pas réellement d'installation du logiciel serveur ou de paramétrage d'un utilisateur comme « hôte gitolite ».

Gitolite dispose de 4 méthodes d'installation. Les personnes utilisant Fedora ou Debian peuvent utiliser un paquet RPM ou DEB à installer. Les personnes disposant d'un accès root peuvent l'installer manuellement. Par ces deux méthodes, tout utilisateur du système peut ainsi devenir un « hôte gitolite ».

Les personnes sans accès root peuvent l'installer avec leur propre utilisateur. Finalement, gitolite peut s'installer en lançant un script sur une station de travail, à partir d'un shell bash (et pour ceux qui se demandent, même le bash livré avec msysgit fonctionne).

Nous allons décrire cette dernière méthode par la suite. Pour les autres méthodes, référez-vous à la documentation.

Commençons par définir un accès par clé publique au notre serveur, de manière à pouvoir se connecter au serveur depuis notre station de travail sans passer par un mot de passe. La méthode suivante fonctionne sous Linux. Pour les stations sous un autre OS, il se peut que vous deviez le faire manuellement. Supposons que vous avez déjà une paire de clés générées via ssh-keygen.

$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver

Ceci va vous demander un mot de passe pour le compte gitolite et définir l'accès par clé publique. C'est une étape essentielle du script d'installation et il est conseillé de bien vérifier qu'on peut ensuite lancer la commande suivante sans obtenir une demande de mot de passe :

$ ssh gitolite@gitserver pwd
/home/gitolite

Ensuite, clonons Gitolite depuis le site principal du projet et lançons le script “easy-install?. Le troisième argument est le nom que nous souhaitons avoir dans le dépôt gitolite-admin ainsi créé.

$ git clone git://github.com/sitaramc/gitolite
$ cd gitolite/src
$ ./gl-easy-install -q gitolite gitserver sitaram

C'est fini ! Gitolite est à présent installé sur le serveur ainsi qu'un nouveau dépôt appelé gitolite-admin dans le dossier personnel de la station de travail. L'administration de gitolite passe par des modifications dans ce dépôt.

La dernière commande produit une certaine quantité d'informations intéressantes. La première fois qu'elle est lancée, une nouvelle paire de clés cryptographiques est créée. Il faudra la protéger par un mot de passe ou appuyer simplement sur la touche entrée pour ne pas en définir. La raison de la définition de cette seconde paire de clé ainsi que son utilisation sont expliquées dans le document « ssh troubleshooting » accompagnant Gitolite.

Les dépôts appelés gitolite-adminet testing sont créés par défaut sur le serveur. Si vous souhaitez cloner l'un d'eux localement (depuis un compte ayant accès SSH console au compte gitolite via authorized_keys), il suffit de saisir :

$ git clone gitolite:gitolite-admin
$ git clone gitolite:testing

Pour cloner ces mêmes dépôts depuis n'importe quel compte :

$ git clone gitolite@servername:gitolite-admin
$ git clone gitolite@servername:testing

L'installation rapide par défaut suffit à la majorité des besoins, mais il existe des moyens de la paramétrer plus finement. Si on retire l'option -q, l'installation passe en mode bavard et trace des informations indiquant chaque étape. Le mode bavard permet aussi de modifier certains paramètres côté serveur, tels que la localisation réelle des dépôts, en éditant un fichier “rc? utilisé par le serveur. Ce fichier “rc? est richement commenté, ce qui devrait facilement permettre de le modifier, de le sauver et de passer à autre chose. Ce fichier contient aussi différents paramètres qui peuvent être changés pour activer ou désactiver certaines fonctionnalités avancées de gitolite.

Une fois l'installation terminée, vous pouvez basculer vers le dépôt gitolite-admin présent dans votre dossier personnel et inspecter ce qui s'y trouve :

$ cd ~/gitolite-admin/
$ ls
conf/  keydir/
$ find conf keydir -type f
conf/gitolite.conf
keydir/sitaram.pub
$ cat conf/gitolite.conf
#gitolite conf
# please see conf/example.conf for details on syntax and features
 
repo gitolite-admin
    RW+                 = sitaram
 
repo testing
    RW+                 = @all

Notez que “sitaram? (le dernier argument de la commande gl-easy-install précédente) détient les permissions en lecture-écriture sur le dépôt gitolite-admin ainsi qu'une clé publique du même nom.

Le fichier de configuration de gitolite présent dans conf/example.conf est extensivement commenté et nous n'en mentionnerons que quelques points cruciaux.

Pour vous simplifier la tâche, vous pouvez grouper les utilisateurs et les dépôts. Les noms de groupes sont juste comme des macros. À leur définition, il importe peu que ce soient des projets ou d’utilisateurs. Cette distinction ne sert que lors de l'utilisation de la « macro ».

@oss_repos      = linux perl rakudo git gitolite
@secret_repos   = fenestra pear
 
@admins         = scott     # Adams, not Chacon, sorry :)
@interns        = ashok     # get the spelling right, Scott!
@engineers      = sitaram dilbert wally alice
@staff          = @admins @engineers @interns

Vous pouvez contrôler les permissions au niveau “ref?. Dans l'exemple suivant, les stagiaires (intern) ne peuvent pousser que sur la branche “int?. Les ingénieurs peuvent pousser toutes les branches dont le nom commence par “eng? et les étiquettes qui commencent par “rc? suivi d'un chiffre. Les administrateurs ont tous les droits (y compris le rembobinage) sur toutes les réfs.

repo @oss_repos
    RW  int$                = @interns
    RW  eng-                = @engineers
    RW  refs/tags/rc[0-9]   = @engineers
    RW+                     = @admins

L'expression après les RW ou les RW+ est une expression rationnelle (ou regex) qui filtre le nom de la référence (ref). Elle s'appelle donc une « refex » ! Bien entendu, une « refex » peut être bien plus puissante que celles montrées ci-dessus et il est inutile de trop chercher si vous n'êtes pas à l'aise avec les regex perl.

De plus, logiquement, Gitolite préfixe les refex qui ne commencent pas par refs/ avec la chaîne refs/heads/.

Une autre particularité importante de la syntaxe du fichier de configuration est que toutes les règles ne sont pas nécessairement à un seul endroit. On peut conserver toute la configuration commune, telle que l'ensemble des règles pour tous les dépôts oss_repo ci-dessus au début puis ajouter des règles spécifiques plus loin, comme :

repo gitolite
    RW+                     = sitaram

Cette règle sera juste ajoutée à l'ensemble des règles préexistantes du dépôt gitolite.

Du coup, il est nécessaire d'expliciter la politique d'application des règles de contrôle d'accès.

Il existe deux niveaux de contrôle d'accès dans gitolite. Le premier réside au niveau du dépôt. Si vous avez un droit d'accès en lecture (resp. en écriture) à n'importe quelle ref du dépôt, alors vous avez accès en lecture (resp. en écriture) au dépôt.

Le second niveau, applicable seulement pour l'accès en écriture se focalise sur les branches et les étiquettes dans un dépôt. L'utilisateur, le type d'accès en cours (Wou +) et le nom de la référence permettent de définir les critères. Les règles d'accès sont vérifiées par ordre d'apparition dans le fichier de configuration, par recherche d'une correspondance sur cette combinaison (en se souvenant que la correspondance de référence est une refex, non une simple comparaison). Si une correspondance est trouvée, l'accès en poussée est accepté. Si aucune correspondance n'est trouvée, l'accès est refusé.

Jusqu'ici, les seuls types de permissions rencontrés ont été R, RW ou RW+. Néanmoins, gitolite connaît une autre permission : - qui signifie “deny?, accès refusé. Cela vous donne bien plus de possibilités, au prix d'une complexité accrue, car à présent l'absence de correspondance n'est plus la seule manière de refuser l'accès, mais il devient nécessaire de faire attention à l'ordre des règles !

Supposons que dans la situation ci-dessus, nous souhaitons que les ingénieurs soient capables de rembobiner n'importe quelle branche excepté master et integ. Voici comment faire :

    RW  master integ    = @engineers
    -   master integ    = @engineers
    RW+                 = @engineers

Une fois encore, il suffit de suivre simplement les règles de haut en bas jusqu'à rencontrer une correspondance pour votre mode d'accès ou de refus. Les poussées en non-rembobinage sur master ou integ sont permises par la première règle. Les poussées en rembobinage à ces références n'ont pas de correspondance dans la première règle et se poursuivent par la seconde qui les refuse. Toute poussée (en rembobinage ou non) à des refs autres que master ou integ ne correspondra pas aux deux premières règles et sera permise par la troisième.

En sus de la restriction sur les branches utilisables par un utilisateur, il est possible de mettre en place des restrictions sur les fichiers qu'il aura droit de toucher. Par exemple, un Makefile (ou tout autre script) n'est pas supposé être modifié par n'importe qui, du fait que de nombreuses choses en dépendent et qu'une modification non maîtrisée pourrait casser beaucoup de choses. Vous pouvez indiquer à gitolite :

repo foo
    RW                  =   @junior_devs @senior_devs
 
    RW  NAME/           =   @senior_devs
    -   NAME/Makefile   =   @junior_devs
    RW  NAME/           =   @junior_devs

Cette fonctionnalité puissante est documentée dans conf/example.conf.

Gitolite a aussi une fonction appelée “branches personnelles? (ou plutôt “espace de branches personnelles?) qui peuvent s'avérer très utiles en environnement professionnel.

Dans le monde de git, une grande quantité d'échange de code se passe par requêtes de tirage. En environnement professionnel, cependant, les accès non authentifiés sont inimaginables et une authentification poste à poste est impossible. Il est donc nécessaire de pousser sur le serveur central et demander à quelqu'un d'en tirer.

Cela provoquerait normalement le même bazar de branches que dans les VCS centralisés, avec en plus la surcharge pour l'administrateur de la gestion des permissions.

Gitolite permet de définir un préfixe d'espace de nom “personnel? ou “brouillon? pour chaque développeur (par exemple, refs/personnel/<nom du dev>). Référez-vous au chapitre “branches personnelles? du fichier doc/3-faq-tips-etc.mkd pour plus de détails.

Gitolite permet de spécifier des dépôts avec jokers (en fait des regex perl), par exemple, au hasard, devoirs/s[0-9][0-9]/a[0-9][0-9]. Ceci est une fonctionnalité très puissante qui doit être activée en positionnant $GL_WILDREPOS = 1; dans le fichier rc. Un nouveau mode de permission devient accessible (« C »). En suivant ces schémas de nommage, les utilisateurs peuvent alors créer des branches dont ils seront automatiquement propriétaires, leur permettant ainsi de leur assigner des droits en lecture ou lecture-écriture pour d'autres utilisateurs avec lesquels ils souhaitent collaborer. Cette fonctionnalité est documentée dans doc/4-wildcard-repositories.mkd.

Nous terminerons cette section avec quelques échantillons d'autres fonctions qui sont toutes décrites, ainsi que d'autres dans les documents faq, trucs et astuces, etc.

Journalisation : Gitolite enregistre tous les accès réussis. Si vous étiez réticent à donner aux utilisateurs des droits de rembobiner (RW+) et qu'un plaisantin a complètement cassé “master?, le journal des activités est là pour vous aider à trouver facilement et rapidement le SHA qui a tout déclenché.

** Git hors du PATH normal : une fonctionnalité d'usage très utile consiste à supporter que git n'est pas installé dans le ?$PATH normal. Cette situation est beaucoup plus commune que l'on croit, des environnements professionnels ou même des fournisseurs d'hébergement refusent d'installer des outils au niveau système et on se retrouve à devoir les placer dans son propre répertoire. Normalement, il est nécessaire d'avertir d'une manière ou d'une autre la partie cliente de git de cette localisation non standard des binaires de git. Avec gitolite, il suffit de choisir une installation verbeuse et de régler ?$GIT_PATH dans les fichiers “rc?. Aucun réglage spécifique côté client n'est à réaliser.

** Rapport sur les droits d'accès : une autre fonctionnalité très utile concerne la prise en charge de la connexion ssh au serveur. Gitolite vous affiche quels dépôts vous pouvez accéder et avec quels droits. Ci-dessous un exemple :

    hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
    the gitolite config gives you the following access:
         R     anu-wsd
         R     entrans
         R  W  git-notes
         R  W  gitolite
         R  W  gitolite-admin
         R     indic_web_input
         R     shreelipi_converter

Délégation : Pour les grands déploiements, il est possible de déléguer la responsabilité de groupes de dépôts à différentes personnes en leur permettant de les gérer de manière autonome. Cela permet de réduire la charge de travail de l'administrateur principal et évite d'en faire un goulet d'étranglement. Cette fonctionnalité est documentée dans le répertoire doc/.

Support de gitweb : Gitolite supporte gitweb de différentes manières. Il est possible de spécifier quels dépôts sont visibles via gitweb. Il est surtout possible de renseigner le « propriétaire » et la « description » affichés par gitweb dans le fichier de configuration de gitolite. Gitweb permet la mise en place d'un mécanisme de contrôle d'accès basé sur l'authentification HTTP, et il est possible de lui faire utiliser un fichier de configuration compilé par gitolite, ce qui signifie que les mêmes règles d'accès (en lecture) s'appliquent à gitweb et à gitolite.

** Miroirs : Gitolite peut vous aider à maintenir de multiples miroirs et à basculer simplement entre eux si le miroir principal tombe en panne.

GitHub est légèrement différent de la plupart des sites d'hébergement de code dans le sens où il utilise un espace de noms pour les projets. Au lieu d'être principalement orienté projet, GitHub est orienté utilisateur. Cela signifie que lorsque j'héberge mon projet grit sur GitHub, vous ne le trouverez pas à github.com/grit, mais plutôt à github.com/schacon/grit. Il n'y a pas de dépôt canonique d'un projet, ce qui permet à un projet de se déplacer d'un utilisateur à l'autre sans transition si le premier auteur abandonne le projet.

GitHub est aussi une société commerciale qui facture les comptes qui utilisent des dépôts privés, mais tout le monde peut rapidement obtenir un compte gratuit pour héberger autant de projets libres que désiré. Nous allons détailler comment faire.

La première chose à faire, c'est de créer un compte utilisateur gratuit. Visitez la page « Plans & Pricing » (plans et prix) à http://github.com/plans et cliquez sur le bouton « Create a free account » (créer un compte gratuit)de la zone « Free for open source » (gratuit pour l'open source) (voir figure 4-2) qui vous amène à la page d'enregistrement.

Vous devez choisir un nom d'utilisateur qui n'est pas déjà utilisé dans le système et saisir une adresse e-mail qui sera associée au compte et un mot de passe (voir figure 4-3).

Si vous l'avez, c'est le bon moment pour ajouter votre clef publique SSH. Nous avons détaillé comment en générer précédemment au chapitre « Petites installations ». Copiez le contenu de la clef publique et collez-le dans la boîte à texte « SSH Public Keys » (clés SSH publiques). En cliquant sur le lien « Need help with public keys? » (besoin d'aide avec les clés publiques ?), vous aurez accès aux instructions (en anglais) pour créer des clés sur la majorité des systèmes d'exploitation. Cliquez sur le bouton « Create an account » (créer un compte) pour avoir accès à votre tableau de bord de nouvel utilisateur (voir figure 4-4).

Vous pouvez ensuite procéder à la création d'un nouveau dépôt.

Commencez en cliquant sur le bouton gris « New Repository » juste à côté de « Your Repositories » (vos dépôts) sur le tableau de bord utilisateur. Un formulaire « Create a New Repository » (créer un nouveau dépôt) apparaît pour vous guider dans la création d'un nouveau dépôt (voir figure 4-5).

Le strict nécessaire consiste à fournir un nom au projet, mais vous pouvez aussi ajouter une description. Ensuite, cliquez sur le bouton « Create Repository » (créer un dépôt). Voilà un nouveau dépôt sur GitHub (voir figure 4-6).

Comme il n'y a pas encore de code, GitHub affiche les instructions permettant de créer un nouveau projet, de pousser un projet Git existant ou d'importer un projet depuis un dépôt Subversion public (voir figure 4-7).

Ces instructions sont similaires à ce que nous avons déjà décrit. Pour initialiser un projet qui n'est pas déjà dans Git, tapez

$ git init
$ git add .
$ git commit -m 'premiere validation'

Dans le cas d'un projet Git local, ajoutez GitHub comme dépôt distant et poussez-y votre branche master :

$ git remote add origin git@github.com:testinguser/iphone_projet.git
$ git push origin master

Votre projet est à présent hébergé sur GitHub et vous pouvez fournir l'URL à toute personne avec qui vous souhaitez le partager. Dans notre cas, il s'agit de http://github.com/testinguser/iphone_projet. Vous pouvez aussi voir dans l'entête de la page de chaque projet qu'il y a deux URL Git (voir figure 4-8).

L'URL « Git Read-Only » (Git en lecture seule) est une URL Git publique en lecture seule que tout le monde peut cloner. Utilisez cette URL pour publier et partager votre dépôt sur un site web ou autre.

Votre URL « SSH » est une URL SSH en lecture/écriture qui ne vous permet de lire et écrire que si vous possédez la clef privée associée à la clef publique téléchargée pour votre utilisateur. Quand d'autres utilisateurs visiteront cette page de projet, ils ne verront pas cette URL, ils ne verront que l'URL publique.

Si vous souhaitez importer un projet public sous Subversion dans Git, GitHub peut vous faciliter la tâche. Il y a un lien « Importing a SVN Repo? Click here » (Vous importez un dépôt Subversion? Cliquez ici) au bas de la page d'instructions. En le cliquant, vous accédez à un formulaire contenant des informations sur le processus d'import et une boîte à texte où vous pouvez coller l'URL de votre dépôt public Subversion (voir figure 4-9).

Si votre projet est très gros, ne suit pas les standards de nommage ou est privé, cette méthode risque de ne pas fonctionner. Au chapitre 7, nous traiterons des imports manuels plus compliqués de projets.

Ajoutons le reste de l'équipe. Si John, Josie et Jessica ouvrent tous un compte sur GitHub, et que vous souhaitez leur donner un accès en écriture à votre dépôt, vous pouvez les ajouter à votre projet comme collaborateurs. Cela leur permettra de pousser leur travail sur le dépôt avec leurs clefs privées.

Cliquez le bouton « Admin » dans l'entête du projet pour accéder à la page d'administration de votre projet GitHub (voir figure 4-10).

Pour accorder à un autre utilisateur l'accès en écriture au projet, cliquez l'onglet « Collaborators » (Collaborateurs). Vous pouvez entrer le nom de l'utilisateur dans la boîte à texte qui apparaît. Au fur et à mesure de votre frappe, une liste déroulante affiche les noms qui correspondent aux caractères tapés. Lorsque vous avez trouvé l'utilisateur correct, cliquez le bouton « Add » (Ajouter) pour ajouter l'utilisateur comme collaborateur au projet (voir figure 4-11).

Lorsque vous avez fini d'ajouter des collaborateurs, vous devriez les voir en liste dans la boîte « Repository Collaborators » (voir figure 4-12).

Si vous devez révoquer l'accès à certaines personnes, vous pouvez cliquer la croix rouge leur correspondant et leur accès en écriture sera effacé. Pour des projets futurs vous pouvez aussi copier des groupes de collaborateurs en copiant les permissions d'un projet existant.

Une fois que vous avez poussé votre projet ou l'avez importé depuis Subversion, votre page principale de projet ressemble à la figure 4-13.

Lorsqu'on visite votre projet, on voit cette page. Elle contient des onglets vers différentes vues des projets. L'onglet « Commits » (validations) affiche une liste des validations dans l'ordre chronologique inverse, similaire à ce qu'afficherait la commande git log. L'onglet « Network » (réseau) affiche tous les utilisateurs ayant dupliqué votre projet et contribué. L'onglet « Downloads » (téléchargements) vous permet de télécharger les exécutables du projet ou de fournir des archives des sources de votre projet à des points balisés. L'onglet « Wiki » fournit un wiki ou vous pouvez commencer à écrire la documentation ou d'autres informations du projet. L'onglet « Graphs » permet de visualiser les contributions et les statistiques. L'onglet principal « Source » sur lequel vous arrivez par défaut affiche le contenu du répertoire principal du projet et met en forme dessous le fichier README s'il en contient un. Cet onglet affiche aussi une boîte contenant les informations de la dernière validation.

Si vous souhaitez contribuer à un projet auquel vous n'avez pas accès en écriture, GitHub encourage à dupliquer le projet. Si le projet vous semble intéressant et que vous souhaitez le modifier, vous pouvez cliquer sur le bouton « Fork » (dupliquer) visible dans l'entête du projet pour faire copier ce projet par GitHub vers votre utilisateur pour que vous puissiez pousser dessus.

De cette manière, les administrateurs de projet n'ont pas à se soucier d'ajouter des utilisateurs comme collaborateurs pour leur donner un accès en écriture. On peut dupliquer un projet et pousser dessus, et le mainteneur principal du projet peut tirer ces modifications en ajoutant les projets dupliqués comme dépôts distants et en fusionnant les changements.

Pour dupliquer un projet, visitez la page du projet (par exemple mojombo/chronic), et cliquez le bouton « Fork » (dupliquer) dans l'entête (voir figure 4-14).

Quelques secondes plus tard, vous êtes redirigés vers une nouvelle page de projet qui indique que ce projet est un dupliqué d'un autre (voir figure 4-15).

C'est tout ce que nous dirons de GitHub, mais il faut souligner que tous ces processus sont très rapides. Vous pouvez créer un compte, ajouter un nouveau projet et commencer à pousser dessus en quelques minutes. Si votre projet est libre, vous pouvez aussi construire une importante communauté de développeurs qui ont à présent la visibilité sur votre projet et peuvent à tout moment le dupliquer et commencer à contribuer. Tout au moins, cela peut s'avérer une manière rapide de démarrer avec Git et de l'essayer.