Erreur Git Push '[distant rejeté] maître -> maître (la branche est actuellement extraite)'
Hier, j’ai posté une question sur la façon de cloner un Git référentiel d’une machine à l’autre, Comment puis-je "clouer" une autre machine?.
Je peux maintenant cloner avec succès un référentiel Git de ma source (192.168.1.2) vers ma destination (192.168.1.1).
Mais quand j'ai modifié un fichier, un git commit -a -m "test" et un git Push, j'obtiens cette erreur sur ma destination (192.168.1.1):
git Push
[email protected]'s password:
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error:
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://[email protected]/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to Push some refs to 'git+ssh://[email protected]/media/LINUXDATA/working'
J'utilise deux versions différentes de Git (1.7 sur la télécommande et 1.5 sur la machine locale). Est-ce une raison possible?
Vous pouvez simplement convertir votre référentiel distant en référentiel nu (il n'y a pas de copie de travail dans le référentiel nu - le dossier contient uniquement les données réelles du référentiel).
Exécutez la commande suivante dans votre dossier de référentiel distant:
git config --bool core.bare true
Supprimez ensuite tous les fichiers sauf .git dans ce dossier. Et vous pourrez alors exécuter git Push dans le référentiel distant sans erreur.
J'ai juste eu la même erreur pendant que je commençais à apprendre Git . Certaines des autres réponses ne sont clairement pas pour quelqu'un de nouveau chez Git!
(Je vais utiliser des termes non techniques pour faire passer l'idée.) Quoi qu'il en soit, ce qui se passe, c'est que vous avez deux référentiels, l'un est l'original que vous avez créé en premier et l'autre le travail que vous venez de faire.
Actuellement, vous êtes dans votre référentiel de travail et utilisez la branche "master". Mais vous êtes également "connecté" dans votre référentiel d'origine à la même branche "maître". Maintenant que vous êtes "connecté" à l'original, Git craint de vous tromper, car vous pourriez travailler sur l'original et tout gâcher. Vous devez donc revenir au référentiel d'origine et faire un "git checkout oneotherbranch", et maintenant vous pouvez pousser sans problèmes.
J'espère que ça aide.
Le message d'erreur décrit ce qui s'est passé. Des versions plus modernes de Git refusent de mettre à jour une branche via un Push si cette branche est extraite.
Le moyen le plus simple de travailler entre deux référentiels non nus est de:
toujours mettre à jour les référentiels par extraction (ou extraction et fusion) ou, si nécessaire,
en poussant vers une branche distincte (une branche d'importation), puis en la fusionnant dans la branche principale de la machine distante.
La raison de cette restriction est que l'opération Push ne fonctionne que sur le référentiel Git distant, elle n'a pas accès à l'index et à l'arborescence de travail. Donc, si cela est autorisé, un envoi Push sur la branche extraite changera le HEAD en incohérence avec l'index et l'arborescence de travail du référentiel distant.
Cela rendrait très facile la validation accidentelle d’un changement qui annule tous les changements proposés et rend également très difficile la distinction entre les changements locaux non engagés et les différences entre le nouveau HEAD, l’index et le arbre de travail qui a été causé par le déplacement Push HEAD.
Résumé
Vous ne pouvez pas accéder à la branche extraite d'un référentiel, car cela dérangerait l'utilisateur de ce référentiel d'une manière qui aboutirait probablement à perte de données et historique . Mais vous pouvez pousser vers n'importe quelle autre branche du même référentiel.
Comme les référentiels nus n'ont jamais d'extraction extraite de branche, vous pouvez toujours transférer vers n'importe quelle branche d'un référentiel nu.
Il existe plusieurs solutions, en fonction de vos besoins.
Solution 1: Utilisez une repostiory nue
Comme suggéré, si sur un ordinateur, vous n'avez pas besoin du répertoire de travail, vous pouvez passer à un référentiel nu. Pour éviter de jouer avec le référentiel, vous pouvez simplement le cloner:
machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo
Maintenant, vous pouvez envoyer tout ce que vous voulez à la même adresse qu'avant.
Solution 2: passer à une branche non extraite
Mais si vous devez extraire le code sur votre <remote> distant, vous pouvez utiliser une branche spéciale pour Push. Supposons que dans votre référentiel local, vous avez appelé votre variable Origin distante et que vous vous trouvez sur le maître de branche. Alors vous pourriez faire
machine2$ git Push Origin master:master+machine2
Ensuite, vous devez le fusionner lorsque vous vous trouvez dans le repo distant Origin:
machine1$ git merge master+machine2
Autopsie du problème
Lorsqu'une branche est extraite, la validation ajoute un nouveau commit avec la tête de la branche actuelle en tant que parent et déplace la tête de la branche pour qu'elle devienne ce nouveau commit.
Alors
A ← B
↑
[HEAD,branch1]
devient
A ← B ← C
↑
[HEAD,branch1]
Mais si quelqu'un pouvait pousser vers cette branche entre les deux, l'utilisateur se retrouverait dans ce que git appelle détaché tête mode:
A ← B ← X
↑ ↑
[HEAD] [branch1]
Maintenant, l'utilisateur n'est plus dans la branche 1, sans avoir explicitement demandé à extraire une autre branche. Pire encore, l'utilisateur est maintenant hors de toute branche , et tout nouveau commit sera simplement en suspens :
[HEAD]
↓
C
↙
A ← B ← X
↑
[branch1]
De manière hypothétique, si à ce stade, l'utilisateur vérifie une autre branche, cette validation pendante devient alors un jeu équitable pour/ garbage collector de Git.
Vous pouvez contourner cette "limitation" en modifiant le .git/config sur le serveur de destination. Ajoutez ce qui suit pour permettre à un dépôt git d'être poussé même s'il est "extrait":
[receive]
denyCurrentBranch = warn
ou
[receive]
denyCurrentBranch = false
Le premier permettra au Push tout en avertissant de la possibilité de gâcher la branche, alors que le second le permettra tout simplement.
Cela peut être utilisé pour "déployer" du code sur un serveur qui n'est pas destiné à l'édition. Ce n'est pas la meilleure approche, mais une rapide pour déployer du code.
J'aime l'idée d'avoir toujours un référentiel utilisable sur la boîte distante, mais au lieu d'une branche factice, j'aime utiliser
git checkout --detach
Cela semble être une toute nouvelle fonctionnalité de Git - J'utilise la version 1.7.7.4 de Git.
git config --local receive.denyCurrentBranch updateInstead
https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155
Utilisez-le dans le référentiel du serveur et il met également à jour l’arborescence de travail si aucun écrasement non suivi n’a lieu.
Il a été ajouté dans Git 2.3 as mentionné par VonC dans les commentaires.
J'ai compilé Git 2.3 et essayé. Exemple d'utilisation:
git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead
cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git Push Origin master:master
cd ../server
ls
Sortie:
a
b
Oui, b a été poussé!
J'ai eu le même problème. Pour moi, j'utilise Git Push pour transférer le code sur mes serveurs. Je ne change jamais le code côté serveur, donc c'est sûr.
Dans le référentiel, vous poussez pour taper:
git config receive.denyCurrentBranch ignore
Cela vous permettra de changer le référentiel alors que c'est une copie de travail.
Après avoir exécuté Git Push, allez sur la machine distante et tapez ceci:
git checkout -f
Ainsi, les modifications que vous avez poussées seront reflétées dans la copie de travail de la machine distante.
Veuillez noter que cela n’est pas toujours sûr si vous apportez des modifications à la copie de travail sur laquelle vous souhaitez travailler.
Vous pouvez recréer votre référentiel de serveur et Push depuis votre maître de succursale local vers le maître de serveur.
Sur votre serveur distant:
mkdir myrepo.git
cd myrepo.git
git init --bare
OK, de votre agence locale:
git Push Origin master:master
Ce que vous avez probablement fait pour causer ceci:
Ce genre de chose se produit lorsque vous lancez un petit programme. Vous êtes sur le point de changer quelque chose qui fonctionnait déjà, alors vous lancez votre sort de niveau 3 d'invalidité perpétuelle:
machine1:~/proj1> git init
et vous commencez à ajouter/commettre. Mais then, le projet commence à s’impliquer davantage et vous souhaitez travailler à partir d’un autre ordinateur (comme votre ordinateur personnel ou votre ordinateur portable). Vous devez donc faire quelque chose comme:
machine2:~> git clone ssh://machine1/~/proj1
et ça clone et tout va bien, et vous travaillez sur votre code depuis machine2.
Ensuite ... vous essayez de pousser vos commits depuis la machine2 et vous obtenez le message d'avertissement dans le titre.
La raison de ce message est que le dépôt Git que vous avez extrait était destiné à être utilisé uniquement pour ce dossier sur la machine1. Vous pouvez très bien utiliser clone, mais cela peut poser problème. La manière "appropriée" de gérer le code à deux endroits différents est d'utiliser un dépôt "nu", comme cela a été suggéré. Un repo nu n'est pas conçu pour que tout travail soit effectué dans il, il est destiné à coordonner les commits provenant de plusieurs sources. C'est pourquoi la réponse la mieux notée suggère supprimer tous les fichiers/dossiers autres que le dossier .git après git config --bool core.bare true.
Clarifier la réponse la mieux notée: La plupart des commentaires de cette réponse disent quelque chose comme "Je n'ai pas supprimé les fichiers non-.git de la machine1 et je pouvais toujours effectuer une validation à partir de machine2". C'est vrai. Cependant, ces autres fichiers sont complètement "divorcés" du dépôt git, maintenant. Allez essayer git status et vous devriez voir quelque chose comme "fatal: cette opération doit être exécutée dans un arbre de travail". Donc, la suggestion de supprimer les fichiers ne vise pas à ce que le commit de machine2 soit work; c'est pour que vous ne soyez pas dérouté et que vous pensiez que git suit toujours ces fichiers. Mais supprimer les fichiers est un problème si vous voulez toujours travailler sur les fichiers sur machine1, n'est-ce pas?
Alors, que devriez-vous vraiment faire?
Dépend de combien de temps vous envisagez de continuer à travailler sur machine1 et machine2 ...
Si vous avez terminé votre développement à partir de machine1 et que vous avez transféré tout votre développement sur machine2 ... faites simplement ce que la réponse la mieux notée suggère: git config --bool core.bare true, puis supprimez éventuellement tous les fichiers/dossiers autres que .git ce dossier, car ils sont non suivis et susceptibles de causer de la confusion.
Si votre travail sur machine2 n'était qu'une tâche ponctuelle, et que vous n'avez pas besoin de poursuivre le développement là-bas ... alors ne vous embêtez pas pour faire un rapport simple; juste ftp/rsync/scp/etc. vos fichiers de la machine * 2 * par-dessus les fichiers de la machine * 1 *, commit/Push de la machine * 1 *, puis supprimez les fichiers de la machine * 2 *. D'autres ont suggéré de créer une branche, mais je pense que c'est un peu compliqué si vous voulez simplement fusionner un développement que vous avez fait de manière ponctuelle à partir d'une autre machine.
Si vous devez poursuivre le développement à la fois sur machine1 et machine2 ... , vous devez configurer les éléments correctement. Vous devez convertir votre repo en un stock nu, then, vous devez en faire un clone sur machine1 pour que vous work puissiez y accéder. Le moyen le plus rapide de le faire est probablement de le faire.
machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1
Très important: parce que vous avez déplacé l'emplacement du dépôt de proj1 à proj1.git, vous devez le mettre à jour dans le fichier .git/config de la machine2. Après cela, vous pouvez valider vos modifications à partir de machine2. Enfin, j'essaie de garder mes pensions nues dans un emplacement central, loin de mes arbres de travail (c'est-à-dire, ne mettez pas "proj1.git" dans le même dossier parent que "proj1"). Je vous conseille de faire de même, mais je voulais garder les étapes ci-dessus aussi simples que possible.
En quelques étapes de configuration, vous pouvez facilement appliquer les modifications apportées à votre site Web à l’aide d’une solution unique.
git Push production
Ce qui est simple et agréable, et vous n'avez pas à vous connecter au serveur distant et à faire un pull ou quoi que ce soit. Notez que cela fonctionnera mieux si vous n'utilisez pas votre caisse de production comme une branche en activité! (Le PO fonctionnait dans un contexte légèrement différent, et je pense que la solution de @Robert Gould l'a bien fait. Cette solution est plus appropriée pour un déploiement sur un serveur distant.)
Vous devez d’abord configurer un référentiel nu quelque part sur votre serveur, en dehors de votre racine Web.
mkdir mywebsite.git
cd mywebsite.git
git init --bare
Puis créez le fichier hooks/post-receive:
#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f
Et rendre le fichier exécutable:
chmod +x hooks/post-receive
Sur votre machine locale,
git remote add production [email protected]:mywebsite.git
git Push production +master:refs/heads/master
Tous ensemble! Désormais, vous pourrez utiliser git Push production pour déployer vos modifications!
Le crédit de cette solution va à http://sebduggan.com/blog/deploy-your-website-changes-using-git/ . Regardez là-bas pour une explication plus détaillée de ce qui se passe.
Vous ne devriez pousser que vers un référentiel nu. Un référentiel nu est un référentiel qui n'a pas de branches extraites. Si vous deviez aller dans un répertoire de référentiel nu, vous ne verriez que le contenu d'un répertoire .git.
Vous avez 3 options
Tirez et repoussez:
git pull; git PushPush dans une branche différente:
git Push Origin master:fooet le fusionner sur remote (soit par
gitou pull-request )git merge fooForcez-le (non recommandé sauf si vous avez délibérément modifié les commits via
rebase):git Push Origin master -fSi le refus persiste, désactivez
denyCurrentBranchsur le référentiel distant:git config receive.denyCurrentBranch ignore
En fait, définir la télécommande sur une branche non extraite est suffisant. Après avoir extrait votre télécommande dans une autre branche, vous pouvez appuyer sur.
J'ai eu le même problème lors de l'utilisation de Git pour synchroniser les référentiels sur mon téléphone Android et mon ordinateur portable. La solution pour moi était de tirer un pull plutôt qu'un Push, comme @CharlesBailey le suggérait.
git Push Origin master sur le référentiel Android échoue pour moi avec les mêmes messages d'erreur que @ hap497 en raison d'un Push vers une extraction non bare d'un référentiel + copie de travail.
git pull droid master sur le référentiel des ordinateurs portables et la copie de travail fonctionne pour moi. Bien sûr, vous devez avoir déjà exécuté quelque chose comme git remote add droid /media/Kingston4GB/notes_repo/.
Les anciennes versions de Git autorisaient les envois vers la branche actuellement extraite d'un référentiel non-nu.
Il s’avère que c’est une chose terriblement déroutante à autoriser. Ils ont donc ajouté le message d’avertissement que vous voyez, qui est également terriblement déroutant.
Si le premier référentiel agit uniquement en tant que serveur, convertissez-le en référentiel nu comme le recommandent les autres réponses.
Si toutefois vous avez besoin d’une branche partagée entre deux dépôts utilisés, vous pouvez le réaliser avec la configuration suivante
Repo1 - agira en tant que serveur et sera également utilisé pour le développement
Repo2 - sera pour le développement seulement
Configurez Repo1 comme suit
Créer une branche sur laquelle partager le travail.
git branch shared_branch
Pour plus de sécurité, vous devez également créer un fichier $ (REPO) .git/hooks/update qui rejette toute modification autre que shared_branch, car vous ne voulez pas que les gens se faufilent dans vos succursales privées.
repo1/.git/hooks (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"
if [ "${refname}" != "refs/heads/shared_branch" ]
then
echo "You can only Push changes to shared_branch, you cannot Push to ${refname}"
exit 1
fi
Maintenant, créez une branche locale dans repo1 où vous ferez votre travail actuel.
git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'
(peut-être besoin de git config --global Push.default upstream pour que git Push fonctionne)
Maintenant, vous pouvez créer repo2 avec
git clone path/to/repo1 repo2
git checkout shared_branch
À ce stade, vous devez configurer repo1 et repo2 pour travailler sur les branches locales qui poussent et extraient shared_branch dans repo1, sans avoir à vous soucier de ce message d'erreur ni à ce que le répertoire de travail ne soit plus synchronisé dans repo1. Quel que soit le flux de travail normal que vous utilisez, cela devrait fonctionner.
OK, si vous voulez un référentiel distant normal, créez une branche supplémentaire et extrayez-la. Poussez-le dans une branche (qui n'est pas extraite) et fusionnez-la avec une qui est active ultérieurement après avoir poussé depuis localement.
Par exemple, sur un serveur distant:
git branch dev
git checkout dev
Sur la configuration locale:
git Push
Sur le serveur distant:
git merge dev
Voici un test que vous pouvez faire pour voir comment fonctionne le serveur bare:
Imaginez que vous ayez un poste de travail et un serveur hébergés sur un site actif et que vous souhaitiez mettre à jour ce site de temps à autre (cela s'applique également à une situation dans laquelle deux développeurs envoient leur travail par l'intermédiaire d'un simple intermédiaire) .
Initialisation
Créez un répertoire sur votre ordinateur local et cd dans celui-ci, puis exécutez ces commandes:
# initialization
git init --bare server/.git
git clone server content
git clone server local
- Tout d'abord, vous créez un répertoire
server(vous remarquerez le .git à la fin). Ce répertoire servira de conteneur pour vos fichiers de référentiel uniquement. - Puis clonez votre référentiel de serveurs dans un répertoire
contentnouvellement créé. Ceci est votre répertoire live/production qui sera servi par votre logiciel serveur. - Les deux premiers répertoires résident sur votre serveur, le troisième est un répertoire local sur votre poste de travail.
Flux de travail
Maintenant, voici le flux de travail de base:
Entrez le répertoire
local, créez des fichiers et validez-les. Enfin, poussez-les vers le serveur:# create crazy stuff git commit -av git Push Origin masterMaintenant, entrez le répertoire
contentet mettez à jour le contenu du serveur:git pullRépétez 1-2. Ici,
contentpeut être un autre développeur qui peut également transmettre au serveur, etlocal, comme vous le retirez.
Je suis sûr que la plupart des lecteurs de cette question s’arrêteront aux deux premières réponses, mais je voudrais quand même proposer ma solution.
J'avais une configuration de projet Web Eclipse + EGit lorsque j'ai rencontré l'erreur décrite. Ce qui m'a aidé, c'est simplement d'utiliser l'application GitHub, qui semble résoudre le problème de façon magique. Même si EGit refusait toujours le Push, l’application de bureau GitHub ne faisait que hausser les épaules et pousser mes modifications. Peut-être qu'il gère la situation de connexion multiple de manière plus élégante.
La meilleure façon de faire est:
mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/
Cela clonera le référentiel, mais ne fera aucune copie de travail dans .../remote. Si vous regardez la télécommande, vous verrez un répertoire créé, appelé currentrepo.git, qui est probablement ce que vous voulez.
Ensuite, depuis votre référentiel Git local:
git remote add remoterepo ..../remote/currentrepo.git
Après avoir apporté des modifications, vous pouvez:
git Push remoterepo master
vérifiez votre .git/config dans le projet de destination:
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[receive]
denyCurrentBranch = updateInstead
Si le core. bare est faux, vous pouvez le définir sur true:
$ git config core.bare true
puis dans votre Push local à distance:
git Push remote_repo // suppose the destination repo is remote_repo
ça va réussir, dans le remote_repo vous pouvez vérifier la version de git.
$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < [email protected]>
Date: Thu May 17 21:54:37 2018 +0800
et maintenant vous ne pouvez pas utiliser git dans votre "espace de travail":
$ git status
fatal: This operation must be run in a work tree
vous devriez remettre bare.bare à false.
$ git config core.bare false
Je devais ré-exécuter git --init dans un référentiel nu existant, ce qui avait créé un répertoire .git dans l'arborescence du référentiel nu - je me suis rendu compte qu'après y avoir entré git status. J'ai supprimé ça et tout allait bien à nouveau :)
(Toutes ces réponses sont excellentes, mais dans mon cas, c'était quelque chose de complètement différent (d'après ce que je peux voir), comme décrit.)
Un article que j’ai trouvé qui pourrait être utile aux autres est Git en 5 minutes.
J'avais un projet Xcode sous contrôle de version Git que je souhaitais utiliser pour passer à un Virtual Distributed Ethernet (VDE) que je possède dans un DC. Le VDE fonctionne Centos 5.
Aucun des articles que j'ai lus sur Git ne parle de référentiels nus. Tout semblait si simple jusqu'à ce que j'essaie ce que je pensais être facile de venir d'un SVN background.
Les suggestions présentées ici pour rendre le référentiel distant nu, ont été travaillées. Encore mieux pour mes besoins était de cloner le projet Xcode en projectname.git, de le copier sur le serveur distant; puis pousse magiquement travaillé. La prochaine étape consistera à faire passer Xcode à Push sans erreurs sur les commits, mais pour le moment, je peux le faire depuis Terminal.
Alors:
cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git [email protected]:repos/<br/>
Pour transmettre les modifications de votre projet Xcode après avoir validé Xcode:
cd /xcode-project-directory<br/>
git Push [email protected]:repos/projectname.git<br/>
Je suis certain qu'il existe une méthode plus douce et plus sophistiquée, mais au minimum, cela fonctionne. Pour que tout soit clair, voici quelques précisions: /xcode-project-directory est le répertoire dans lequel votre projet xcode est stocké. Il est probablement /Users/Your_Name/Documents/Project_Name. Nomprojet est littéralement le nom du projet, mais il peut s'agir de tout ce que vous souhaitez appeler. il. Git s'en fiche, vous allez le faire.
Pour utiliser scp, vous devez disposer d'un compte utilisateur sur le serveur distant autorisé SSH access. Tous ceux qui utilisent leur propre serveur auront cela. Si vous utilisez l'hébergement mutualisé ou similaire, vous risquez de ne pas avoir de chance.
remotehost.com est le nom de votre hôte distant. Vous pouvez aussi facilement utiliser son adresse IP. Pour plus de clarté, j’utilise Gitosis sur l’hôte distant avec des clés SSH. Par conséquent, je ne suis pas invité à saisir un mot de passe lorsque je clique. L'article Hébergement de référentiels Git, la méthode simple (et sécurisée) vous explique comment configurer tout cela.
Vous devrez changer le fichier de configuration sur le serveur distant une fois que vous aurez créé un référentiel vide (nu), par exemple.
root@development:/home/git/repository/my-project# cat config
là tu verras
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
Vous allez rendre ceci nu à false à true et j'ai supprimé logallrefupdates = true (pas sûr de son utilisation!)
à
[core]
repositoryformatversion = 0
filemode = true
bare = true
Vous pouvez tester la suite
$ git remote show Origin
* remote Origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)
Cette branche HEAD: (inconnu) sera affichée si vous ne pouvez pas appuyer sur. Ainsi, si la branche HEAD est inconnue, vous devez passer de nu à vrai et, une fois le transfert réussi, vous pourrez réutiliser le
git remote show Origin
et vous allez voir
HEAD branch: master
Je viens de rencontrer ce problème avec un référentiel de déploiement git sur Heroku .
Je ne sais pas pourquoi Heroku a un référentiel non nu de leur côté, mais comme solution de contournement, j'ai pu réinitialiser le référentiel distant et effectuer un nouveau chargement.
Vous ne devriez pas utiliser la copie de Heroku de votre référentiel comme seul référentiel git pour la collaboration, mais juste au cas où, je dirai clairement: Ne le faites pas à moins d'être sûr d'avoir une copie complète de votre référentiel stockée en toute sécurité autre que Heroku. Une réinitialisation supprimera le contenu du référentiel.
Réinitialiser:
- Installez le Heroku toolbelt (qui contient le client en ligne de commande) si vous ne l’avez pas déjà fait.
Installez le plugin heroku-repo si vous ne l’avez pas déjà fait.
heroku plugins:install https://github.com/heroku/heroku-repo.gitEffectuez la réinitialisation, ce qui supprime le référentiel et en crée un nouveau, vide.
heroku repo:resetPoussez sur votre télécommande Heroku comme vous le feriez normalement; ça va tout remettre en ligne.
Utiliser ceci pour le pousser vers la branche en amont distante a résolu ce problème pour moi:
git Push <remote> master:Origin/master
La télécommande n’avait pas accès au dépôt en amont, c’était donc un bon moyen d’obtenir les dernières modifications dans cette télécommande
Juste au cas où quelqu'un le trouverait utile. Pour moi, c'était un problème d'autorisations du serveur git. J'ai extrait le projet depuis le début et j'ai poussé un fichier simple, puis le "Push rejeté: le Push to Origin/maître a été rejeté"
Pour moi, la solution de travail est:
À DISTANCE:
git checkout -b some_tmp_name
SUR LOCAL:
git Push
À DISTANCE:
git checkout master
git branch -d some_tmp_name
Mais ce n'est pas la vraie solution, c'est juste une solution de contournement.