Pourquoi ne puis-je pas pousser à partir d'un clone peu profond?
Le git clone --depth L'option de commande indique
--depth <depth>
Create a shallow clone with a history truncated to the specified number of revisions.
A shallow repository has a number of limitations
(you cannot clone or fetch from it, nor Push from nor into it),
but is adequate if you are only interested in the recent history of a large project with a long history,
and would want to send in fixes as patches.
Pourquoi les clones peu profonds ont-ils cette limitation? Pourquoi est-ce un workflow de patchs uniquement?
Pour certains workflows de projet, je dois transmettre uniquement le dernier commit d'une branche unique à un codeur, puis les faire pouvoir Push leurs développements (avance rapide) vers le serveur principal. Ceci en partie pour la sécurité, la protection IP et la taille du référentiel, et en partie pour réduire la confusion qu'un gros référentiel apporterait à un codeur naïf. Existe-t-il un workflow git qui permet cela?
Mise à jour: D'après la réponse de Karl Bielefeldt, le git checkout --Orphan devrait être la bonne réponse. Mais il faut encore "cloner" cette branche seule au nouvel utilisateur, et pouvoir la pousser efficacement.
La page de manuel indique:
git checkout [-q] [-f] [-m] [[-b|-B|--Orphan] <new_branch>] [<start_point>] --OrphanCréez une nouvelle branche orpheline, nommée
<new_branch>, a commencé depuis<start_point>et basculez dessus. Le premier commit effectué sur cette nouvelle branche n'aura pas de parents et ce sera la racine d'une nouvelle histoire totalement déconnectée de toutes les autres branches et commits.L'index et l'arborescence de travail sont ajustés comme si vous aviez précédemment exécuté
git checkout <start_point>. Cela vous permet de démarrer un nouvel historique qui enregistre un ensemble de chemins similaires à<start_point>en exécutant facilementgit commit -apour valider la racine.Cela peut être utile lorsque vous souhaitez publier l'arborescence à partir d'une validation sans exposer son historique complet. Vous pouvez le faire pour publier une branche open source d'un projet dont l'arborescence actuelle est "propre", mais dont l'historique complet contient des bits de code propriétaires ou autrement encombrés.
Si vous souhaitez démarrer un historique déconnecté qui enregistre un ensemble de chemins totalement différent de celui de
<start_point>, vous devez alors effacer l'index et l'arborescence de travail juste après avoir créé la branche Orphan en exécutantgit rm -rf .depuis le niveau supérieur de l'arborescence de travail. Ensuite, vous serez prêt à préparer vos nouveaux fichiers, à repeupler l'arborescence de travail, en les copiant d'ailleurs, en extrayant une archive tar, etc.
Le lien de VonC vers les commentaires de Junio est intéressant. Je pense que le manuel devrait fournir des conseils dans ce cas, et permettre la bonne commande [par ex. clone <branch> --options] pour extraire uniquement la partie pertinente du dépôt. De toute évidence, la probabilité de réussite de Push est augmentée par la présence de quelques validations liées et SHA1 au bas de l'historique qui verrouillera la mise en correspondance.
Mise à jour Git 1.9.0: notes de version du 14 février 2014.
"La récupération à partir d'un référentiel cloné superficiellement était auparavant interdite, principalement parce que les chemins de code impliqués n'étaient pas soigneusement vérifiés et nous n'avons pas pris la peine de prendre en charge une telle utilisation. Cette version tente de permettre le transfert d'objets hors d'un référentiel cloné superficiellement de manière plus contrôlée (c'est-à-dire que le récepteur devient un référentiel superficiel avec un historique tronqué). "
C'est une bonne nouvelle pour les cloners peu profonds. Suivant - Clones étroits éventuellement.
Existe-t-il un workflow git qui permet cela?
Oui, c'est pour envoyer des correctifs sous forme de correctifs. git format-patch est spécialement conçu pour permettre cela. C'est ce qu'on appelle un flux de travail "gatekeeper", si vous voulez google pour plus de détails. Il est difficile de croire qu'une organisation aussi préoccupée par la "sécurité et la protection de la propriété intellectuelle" que la vôtre n'utilise pas déjà quelque chose de similaire, où une personne ou un petit groupe est responsable de la vérification des modifications "non fiables" avant de les intégrer dans la version réelle.
Sur la base de votre commentaire, j'ai maintenant une meilleure idée de vos besoins. Ce que je recommanderais, c'est de créer une branche orpheline (voir git checkout --Orphan ), à partir du point où vous voulez que vos développeurs commencer. Clonez uniquement cette branche dans un référentiel différent accessible à ces développeurs et laissez-les cloner, pousser et extraire normalement de ce référentiel.
Ensuite, lorsque vous devez réintégrer leurs modifications dans le référentiel protégé officiel, tirez simplement leur branche, faites-en une copie avec git branch afin de ne pas écraser votre orphelin d'origine (au cas où vous voudriez répéter le processus plus tard), puis de rebaser la copie sur votre point de branchement d'origine et de fusionner ou quoi que ce soit comme d'habitude. L'historique semblera avoir fonctionné directement à partir de votre dépôt protégé.
C'est un peu plus compliqué que la normale, mais c'est le prix à payer pour l'isolement supplémentaire.