Guide des espaces Git

Un dépôt Git de Flow est un vrai dépôt (tu le clones et tu y fais des push avec le git que tu utilises déjà) qui vit dans Flow plutôt que sur un service externe. Le code, les tasks et les pull requests se trouvent au même endroit que tes fichiers : même connexion, mêmes membres et permissions, même copie de sécurité, même instance, européenne ou dans ton entreprise.

Il est fait pour ceux qui ne veulent pas (ou ne peuvent pas) laisser sortir leur code : le dépôt est un espace comme les autres, avec ses membres et deux rôles (éditeur fait des push, lecteur clone et lit), plus les administrateurs, qui peuvent tout faire. Les dépôts apparaissent dans la section Dépôts de la barre latérale, et occupent de la place dans le quota de l'offre comme tout le reste.

Dans le navigateur, tu trouves cinq onglets : Code, Commits, Tasks, Pull requests et Accès. Les deux premiers se consultent, les autres s'utilisent : le travail d'équipe (qui fait quoi, ce qui entre dans la branche principale) se passe là.

Le clone et le push passent par HTTPS, avec des identifiants faits exprès :

• nom d'utilisateur = ton adresse email ;
• mot de passe = un mot de passe Git, que tu crées toi-même dans l'onglet Accès du dépôt (« Comment se connecter », avec la commande de clone prête à copier).

Le mot de passe ne s'affiche qu'au moment de sa création : copie-le dans le gestionnaire d'identifiants de git (sur Mac osxkeychain, sur Windows Git Credential Manager) et il ne te sera plus demandé. Si tu le perds, il ne se récupère pas : tu en crées un autre et tu révoques l'ancien. Tes mots de passe Git, tu les vois et tu les révoques dans Compte → Git ; un mot de passe vaut pour tous les dépôts auxquels tu as accès, et pour rien d'autre : il n'ouvre pas l'app et ne vaut pas pour l'API.

Qui peut faire quoi, c'est le rôle dans l'espace qui le décide : éditeur fait des push de branches et de tags comme sur n'importe quel remote, lecteur seulement clone et fetch. Qui n'est pas membre ne voit pas du tout le dépôt.

L'onglet Code montre l'arborescence des fichiers sur la branche choisie, et l'accueil du dépôt ouvre le README de la racine, comme tu t'y attends. Les fichiers texte se lisent là ; pour un binaire ou un fichier très volumineux, le navigateur ne fait pas semblant : il te dit de cloner.

L'onglet Commits est l'historique de la branche : chaque commit s'ouvre sur son diff. Dans le texte des tasks et des commentaires, un sha mène directement au diff de ce commit.

Le navigateur est fait pour lire et décider : on écrit en local, avec son propre éditeur, et on fait un push. La seule écriture qui passe par le web est celle qui doit y passer : fusionner une pull request.

Les tasks, c'est là que l'équipe se parle : bugs à corriger, modifications à demander, choses à faire, discussions. Quatre types (Bug, Demande de modification, To-do, Discussion) et pour le reste la même forme : titre, texte en Markdown, commentaires, état ouvert/fermé.

Chaque task a un numéro : écrire #12 dans un task, un commentaire ou une pull request crée le lien ; un sha de commit devient le lien vers son diff. Un task peut être assigné à un membre, avoir des étiquettes et une priorité ; les filtres en haut de la liste (« Ouverts », « Mes tasks », la recherche) servent à s'y retrouver quand les tasks deviennent nombreux.

Ce que tu n'as pas encore lu se voit : le task avec du nouveau est en gras, et l'onglet affiche le compteur « non lu(s) ». Les emails suivent ta préférence dans Compte → Notifications par email → Tasks : qui participe à un task (auteur, personne assignée, qui a commenté) reçoit les attributions, les commentaires et les fermetures.

On peut joindre des fichiers à un task : ils vont dans un dossier « Task #n » de l'espace, et la référence reste dans le texte. Pratique pour les captures d'écran, les logs, les documents de départ : ils restent dans le dépôt de ceux qui y travaillent, et non dans une messagerie externe.

Une pull request propose de fusionner une branche dans une autre. Tu l'ouvres en choisissant les deux branches (une seule PR ouverte par branche à la fois), et l'onglet t'indique tout de suite et en direct où elle en est : « fusionnable sans conflit : n commits », ou bien la liste des fichiers en conflit, que tu résous en local, et au push suivant l'onglet se met à jour.

En dessous se trouvent les commits à venir et le diff complet. On commente en bas ou sur une ligne précise du diff : chaque ligne ouvre un fil avec Répondre et Résoudre, et les fils sur des lignes qu'un nouveau push a modifiées ne se perdent pas : ils passent en fin de liste, avec leur chemin et leur numéro de ligne.

Les reviews donnent le verdict : Approuver ou Demander des modifications (jamais sur sa propre PR). C'est le dernier verdict de chacun qui compte, et une approbation vaut pour la version de la branche sur laquelle elle a été donnée : après un nouveau push, elle est marquée « sur une version précédente de la branche » et ne compte plus.

Fusionner depuis le web, en choisissant comment les commits entrent :

• commit de merge : l'historique reste tel quel, avec un commit de fusion signé par la personne qui clique ;
• squash : tous les commits réunis en un seul, signé par la personne qui a ouvert la PR ;
• rebase : les commits remis à la suite au-dessus de la destination, sans commit de merge.

Il y a l'option « supprimer la branche après la fusion », et si tu fusionnes plutôt depuis le terminal avec git, la PR s'en aperçoit toute seule et se marque « Fusionnée avec git ».

Sur une branche protégée, personne ne fait de push direct, pas même les éditeurs : qui essaie reçoit un refus du serveur, avec la raison écrite. On n'entre dans la branche que d'une seule façon : en fusionnant une pull request depuis le web.

On protège une branche depuis l'onglet Accès (il faut un administrateur), et pour chaque branche on peut exiger un nombre d'approbations : la PR ne se fusionne que quand il y a assez de reviews approuvées, et une review « demander des modifications » bloque tant qu'elle ne change pas. L'administrateur peut fusionner malgré tout : la règle discipline l'équipe, elle ne lui retire pas les clés.

C'est la façon de dire « sur main, on n'arrive qu'avec une PR relue », et de le faire respecter par le serveur plutôt que par un accord verbal.

Chaque push est mis en sécurité aussitôt, dans la même archive protégée que tes fichiers : copies redondantes, contrôles continus, restauration automatique. Il n'y a rien à configurer et rien à retenir.

La page du dépôt t'indique quand la dernière copie a été faite (« Copie de sécurité à jour… ») et, si une copie n'a pas réussi, elle te l'écrit.

Dans le quota de l'offre, le dépôt pèse ce qu'il pèse vraiment, avec la déduplication qui vaut pour tout le reste : un dépôt normal occupe peu de place.

Le mot de passe Git ouvre aussi une porte de plus : les routes API des tasks et des pull requests (/api/repos/…/tasks et /api/repos/…/pulls). Avec un curl authentifié (utilisateur ton adresse email, mot de passe le mot de passe Git), on liste les tasks, on lit une PR, on commente, on joint un fichier à un task ou à une PR. Seulement ces routes : pour le reste de l'API, il faut un vrai jeton API (la page Développeurs en parle).

C'est utile à qui automatise son propre flux de travail (scripts, outils de développement, agents) sans distribuer des identifiants plus larges que nécessaire : le mot de passe Git reste révocable en un clic depuis Compte → Git, et son périmètre est le travail sur le dépôt.