Quel est ce message d'avertissement Git lors de l'envoi de modifications à un référentiel distant?
La description est un peu laconique. J'ai simplement ajouté un fichier sur ma branche principale locale et l'ai repoussé vers un référentiel distant. Une idée pourquoi cela arrive?
avertissement: mise à jour de la branche actuelle avertissement: la mise à jour de la branche actuellement extraite peut provoquer de la confusion, avertissement: car l'index et l'arborescence de travail ne reflètent pas les changements qui se trouvent dans HEAD. avertissement: Par conséquent, vous pouvez voir les modifications que vous venez d'y insérer. avertissement: annulé lorsque vous exécutez 'git diff' là-bas, et vous pouvez souhaiter un avertissement : pour exécuter "git reset --hard" avant de commencer à travailler pour récupérer. avertissement: avertissement: vous pouvez définir la variable de configuration "receive.denyCurrentBranch" sur avertissement: "refuser 'dans le référentiel distant pour interdire de pousser dans son avertissement : branche en cours. avertissement: pour permettre de pousser dans la branche en cours, vous pouvez le définir sur' ignorer '; avertissement : mais ce n'est pas recommandé à moins que vous ne vous soyez arrangé pour mettre à jour son travail avertissement: arborescence pour correspondre à ce que vous avez poussé d'une autre manière. avertissement: avertissement: pour supprimer ce message, vous pouvez le régler sur "avertir". avertissement: avertissement: Notez que la valeur par défaut changera dans une future version de git Avertissement: pour refuser la mise à jour de la branche actuelle à moins que vous ayez l'avertissement : Variable de configuration définie sur 'ignorer' ou 'avertir'.
En fait, cela signifie à peu près exactement ce qu'il dit: quelqu'un travaille dans le référentiel vers lequel vous poussez, et que quelqu'un a actuellement extrait exactement la même branche que vous poussez.
C'est très déroutant, car maintenant il pense avoir vérifié la dernière version de la branche, alors qu'en fait, vous venez de mettre à jour la branche vers une version plus récente. Alors, quand il exécute maintenant git commit, son commit annulera essentiellement tous les commits que vous venez de pousser. Et quand il court git diff il verra le contraire de tout ce que vous venez de pousser, même s'il n'a peut-être même rien changé.
Pour cette raison, il est généralement considéré comme une mauvaise pratique de pousser vers un référentiel non nu; vous ne devez jamais pousser que pour mettre à nu les référentiels, c'est-à-dire les référentiels qui n'ont pas de copie de travail jointe. À tout le moins, vous devez vous assurer de ne pas pousser vers la branche actuellement extraite, mais en général, vous ne devez pas simplement mettre votre code dans le référentiel de quelqu'un d'autre, vous devez lui demander de vous retirer à la place.
Dans certains cas spéciaux, comme lorsque vous servez un site Web à partir d'un référentiel Git et que vous souhaitez mettre à jour le site Web en le poussant, il est en fait judicieux de pousser vers la branche actuellement extraite, mais dans ce cas, vous devez vous assurer que vous avez installé un hook qui met à jour la mise à jour de la copie de travail extraite, sinon votre site Web ne sera jamais mis à jour.
avec Git 2.3.0, février 2015
Si personne ne travaille dans ce référentiel distant non nu, il devrait être possible de pousser vers une branche extraite.
Mais pour être plus sûr dans cette opération, vous pouvez maintenant (avec Git 2.3.0, février 2015), faire dans ce dépôt à distance:
git config receive.denyCurrentBranch updateInstead
Il est plus sécurisé que config receive.denyCurrentBranch=ignore: il n'autorisera le Push que si vous n'annulez pas la modification en cours.
Voir commit 1404bcb par Johannes Schindelin (dscho) :
receive-pack: ajoutez une autre option pourreceive.denyCurrentBranchLors de la synchronisation entre les répertoires de travail, il peut être pratique de mettre à jour la branche actuelle via '
Push' plutôt que 'pull', par exemple lors de l'envoi d'un correctif à l'intérieur d'une machine virtuelle ou lors de l'envoi d'un correctif effectué sur la machine d'un utilisateur (où le développeur n'est pas libre d'installer un démon ssh et encore moins de connaître le mot de passe de l'utilisateur).La solution de contournement courante - pousser dans une branche temporaire puis fusionner sur l'autre machine - n'est plus nécessaire avec ce correctif.
La nouvelle option est:
updateInsteadMettez à jour l'arborescence de travail en conséquence, mais refusez de le faire en cas de modifications non validées.
Le commit 4d7a5ce ajoute plus de tests et mentionne:
Le précédent teste uniquement le cas où un chemin à mettre à jour par Push-to-deploy a un changement incompatible dans l'arborescence de travail de la cible qui a déjà été ajouté à l'index, mais la fonctionnalité elle-même veut exiger que l'arborescence de travail soit beaucoup plus propre que ce qui est testé.
Ajoutez une poignée de tests supplémentaires pour protéger la fonctionnalité contre les changements futurs qui, par erreur (du point de vue de l'inventeur de la fonctionnalité), assouplissent l'exigence de propreté, à savoir:
- Un changement uniquement dans l'arborescence de travail mais pas dans l'index est toujours un changement à protéger;
- Un fichier non suivi dans l'arborescence de travail qui serait écrasé par un Push-to-deploy doit être protégé;
- Un changement qui arrive à rendre un fichier identique à ce qui est poussé est toujours un changement à protéger (c'est-à-dire que l'exigence de propreté de la fonctionnalité est plus stricte que celle de la caisse).
En outre, testez qu'une modification stat-only de l'arborescence de travail n'est pas une raison pour rejeter un Push-to-deploy.
avec Git <2.3.0, février 2015
L'approche la plus courante consiste à créer un référentiel nu à partir du référentiel non nu et à avoir à la fois le point de dépôt git distant/local non nu au référentiel nu nouvellement créé.
C'est le même problème que Cette question , la solution est d'utiliser git init --bare ou git clone --bare.