Cibler un dépôt et configurer les outils Git

Les grands dépôts, les fichiers volumineux et les différentes identités de signature ont chacun leurs réglages. Ouvrez l'action adaptée au dépôt actif, examinez l'aperçu et appliquez le changement nécessaire à votre tâche.

Cibler un monorepo avec sparse checkout

1. Ouvrez sparse checkout et sélectionnez les répertoires nécessaires. Filtrer la liste conserve vos choix ; sélectionner un dossier parent rend superflues les sélections de ses descendants.
2. Vérifiez le nombre de fichiers visibles. Le mode cone conserve les répertoires choisis, les fichiers à la racine et ceux directement dans les répertoires ancêtres.
3. Choisissez sparse index uniquement si vos autres outils Git le prennent en charge. Il peut réduire l'index ; il ne garantit pas des builds plus rapides et n'installe pas les dépendances du projet.
4. Appliquez la sélection vérifiée. Des modifications en attente, des fichiers ignorés ou une autre opération Git peuvent bloquer le changement. Résolvez l'état indiqué et générez un nouvel aperçu si le dépôt a changé.
5. Utilisez l'action de restauration de l'arbre complet pour retrouver tous les fichiers suivis.

Cela change les fichiers suivis présents dans l'arbre de travail, sans modifier l'historique complet du dépôt. Aucun partial clone n'est effectué. Les configurations non-cone existantes peuvent être désactivées, mais le sélecteur ne les modifie pas. Les limites actuelles sont de 250 000 fichiers, 20 000 répertoires et 1 000 répertoires sélectionnés ; le dépassement est signalé, sans tronquer silencieusement la sélection.

Gérer les gros fichiers avec Git LFS

Ouvrez le panneau des extensions du dépôt pour inspecter Git LFS, ses fichiers, la disponibilité des objets et les règles du .gitattributes à la racine. Les actions exigent Git LFS 3.8.1 ou ultérieur installé sur l'ordinateur.

1. Installez la configuration LFS dans ce dépôt si nécessaire. Cela configure le dépôt, sans installer l'exécutable Git LFS. Des chemins de hooks partagés ou non sûrs peuvent bloquer l'action ; les hooks existants ne sont pas remplacés de force.
2. Ajoutez ou retirez un motif de suivi et confirmez. Vérifiez le changement de .gitattributes et incluez-le dans un commit si nécessaire.
3. Sélectionnez un distant pour récupérer les objets LFS de HEAD. Matérialisez ensuite les objets disponibles dans les fichiers de travail au besoin.

Le panneau affiche jusqu'à 2 000 fichiers et signale une couverture partielle. Il ne modifie pas tous les fichiers d'attributs imbriqués, ne migre pas l'historique existant vers LFS, ne purge pas les objets et ne les envoie pas automatiquement. Suivre un motif ne convertit pas les anciens commits.

Mettre à jour un sous-module vers une cible précise

Dans le même panneau, sélectionnez un sous-module et comparez son commit actuel à celui enregistré dans l'index du dépôt parent. Vérifiez l'initialisation et les changements en attente avant la mise à jour.

La mise à jour initialise si nécessaire, récupère les données et effectue le checkout du commit enregistré en detached HEAD. Elle n'avance pas vers le dernier commit de la branche distante, ne change pas le commit enregistré par le parent et ne met pas à jour récursivement les sous-modules imbriqués. Les chemins modifiés ou non sûrs et les opérations en cours sont refusés. Ouvrez le sous-module dans son propre contexte Riff pour y travailler.

Une récupération annulée peut laisser des objets téléchargés ou un sous-module partiellement initialisé. Lisez l'état actualisé avant de réessayer ; l'annulation ne signifie pas que toutes les étapes précédentes ont été défaites.

Appliquer un profil d'identité ou de signature

1. Ouvrez l'identité du dépôt et vérifiez l'auteur effectif, la source de configuration et la politique de l'organisation. Choisissez l'identité Git, le compte Gapfy lorsqu'il est disponible ou le comportement par défaut autorisé par la politique.
2. Enregistrez un profil nommé pour le réutiliser. Enregistrer ou charger le profil ne modifie pas le dépôt ; vérifiez et confirmez Appliquer séparément.
3. Choisissez la signature héritée, OpenPGP ou SSH selon vos besoins. Indiquez un identifiant de clé ou une référence à une clé publique SSH. Riff n'importe ni ne stocke de clés privées de signature. Désactiver la signature exige un choix explicite.
4. Vérifiez la portée cible. Avec une configuration propre au worktree activée, Appliquer modifie ce worktree ; sinon, l'action modifie la configuration partagée du dépôt. Elle ne réécrit ni la configuration globale ni les fichiers inclus.
5. Inspectez la signature de HEAD. Le résultat distingue l'absence de commit, un commit non signé, une signature valide et une signature non vérifiée, sans créer de commit de test.

La politique d'identité de l'organisation prévaut sur le profil. La vérification sur l'ordinateur ne prouve pas que le prochain commit pourra être signé ni qu'un hébergeur distant fera confiance à la signature. Configurez séparément l'outil, l'agent et la confiance selon les exigences de votre organisation.

Pour des branches dépendantes, utilisez les stacks et leur publication coordonnée. Pour des tâches indépendantes, utilisez les contextes de travail et worktrees.