Git push error "[rejeté à distance] master - > master (la branche est actuellement cochée)"

vous pouvez simplement convertir votre dépôt distant en dépôt nu (il n'y a pas de copie de travail dans le dépôt nu - le dossier ne contient que les données du dépôt proprement dit).

exécutez la commande suivante dans votre dossier de dépôt distant:

git config --bool core.bare true

puis supprimer tous les fichiers sauf .git dans ce dossier. Puis vous pourrez effectuer git push dans le dépôt distant sans aucune erreur.

j'ai eu la même erreur quand j'ai commencé à apprendre Git . Certains des autres réponses sont clairement pas pour quelqu'un de nouveau à Git!

(je vais utiliser des termes non techniques pour faire passer l'idée.) De toute façon, ce qui se passe est que vous avez deux dépôts, l'un est l'original, vous fait d'abord, et de l'autre le travail.

en ce moment vous êtes dans votre dépôt de travail et vous utilisez la branche" master". Mais il se trouve aussi que vous êtes "connecté" dans votre dépôt original à la même branche "master". Maintenant, puisque vous êtes "connecté" dans l'original, Git les craintes que vous pourriez gâcher parce que vous pouvez travailler sur l'original et vis les choses. Vous devez donc retourner au dépôt d'origine et faire une "git checkout somethotherbranch", et maintenant vous pouvez pousser sans problème.

j'espère que cela aidera.

Le message d'erreur décrit ce qui s'est passé. Les versions plus modernes de Git refusent de mettre à jour une branche via un push si cette branche est cochée.

la façon la plus facile de travailler entre deux dépôts non-nus est soit de

1. Toujours mettre à jour les dépôts par pull (ou fetch and merge) ou, si vous devez,

2. en poussant vers une branche distincte (une branche d'importation) et puis fusionner cette branche dans la branche principale sur la machine distante.

la raison de cette restriction est que l'opération push ne fonctionne que sur le dépôt Git distant, il n'a pas accès à l'arborescence index et working. donc, si on le permet, une poussée sur la branche cochée changerait le HEAD pour être incompatible avec l'arbre d'index et de travail sur le dépôt distant.

cela rendrait très facile de commettre accidentellement un changement qui annule tous les changements poussés et rend également très difficile de distinguer entre les changements locaux qui n'ont pas été commis et les différences entre le nouveau HEAD , l'indice et l'arbre de travail qui ont été causés par le mouvement de poussée HEAD .

résumé

vous ne pouvez pas pousser à la branche cochée d'un dépôt parce qu'il serait en désordre avec l'utilisateur de ce dépôt d'une manière qui se terminera très probablement avec perte de données et d'histoire . Mais vous pouvez passer à n'importe quelle autre branche du même dépôt.

comme les dépôts nus n'ont jamais de branche vérifiée, vous pouvez toujours pousser vers n'importe quelle branche d'un dépôt nu.

il y a plusieurs solutions, selon vos besoins.

Solution 1: Utiliser un Nu-Repostiory

comme suggéré, si sur une machine, vous n'avez pas besoin du répertoire de travail, vous pouvez vous déplacer vers un dépôt nu. Pour éviter de jouer avec le dépôt, vous pouvez simplement le cloner:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

Maintenant, vous pouvez pousser tout ce que vous voulez à la même adresse qu'avant.

Solution 2: Non-Check-Out Branch

Mais si vous avez besoin de vérifier le code de votre télécommande <remote> , alors vous pouvez utiliser une branche spéciale de pousser. Disons que dans votre dépôt local vous avez appelé votre télécommande origin et que vous êtes sur branch master. Alors vous pourriez faire

machine2$ git push origin master:master+machine2

alors vous devez le fusionner lorsque vous êtes dans le origin Remote repo:

machine1$ git merge master+machine2

autopsie du problème

Lorsqu'une branche est cochée, committing ajoutera une nouvelle commit avec la tête de la branche courante comme parent et déplacera la tête de la branche pour être cette nouvelle commit.

Donc

A ← B
    ↑
[HEAD,branch1]

devient

A ← B ← C
        ↑
    [HEAD,branch1]

mais si quelqu'un pouvait pousser à cette branche entre les deux, l'utilisateur se retrouverait dans ce que git appelle tête détachée mode:

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

maintenant le l'utilisateur n'est plus dans branch1, sans avoir explicitement demandé de vérifier une autre branche. Pire, l'utilisateur est maintenant en dehors de toute branche , et tout nouveau commit sera juste pendaison :

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Hypothétiquement, si, à ce stade, l'utilisateur vérifie une autre branche, puis cette balançant commettre devient un jeu équitable pour Git garbage collector .

vous pouvez contourner cette" limitation "en éditant le .git/config sur le serveur de destination. Ajouter ce qui suit pour permettre à un dépôt git d'être poussé même s'il est "vérifié":

[receive]
denyCurrentBranch = warn

ou

[receive]
denyCurrentBranch = false

le premier permettra la poussée tout en avertissant de la possibilité de saboter la branche, tandis que le second permettra juste tranquillement.

Ceci peut être utilisé pour "déployer" code sur un serveur qui est pas fait pour l'édition. Ce n'est pas la meilleure approche, mais une approche rapide pour déployer le code.

j'aime l'idée d'avoir encore un dépôt utilisable sur la boîte distante, mais au lieu d'une branche factice, j'aime utiliser:

git checkout --detach

cela semble être une très nouvelle caractéristique 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

utilise cela sur le dépôt du serveur, et il met également à jour l'arbre de travail si aucun écrasement non suivi ne se produirait.

Il a été ajouté dans Git 2.3 comme mentionné par VonC dans les commentaires.

j'ai compilé Git 2.3 et lui a donné un essai. 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

Yay, b a été repoussée!

j'ai eu le même problème. Pour moi, j'utilise git push pour déplacer le code vers mes serveurs. Je ne change jamais le code du côté du serveur, donc c'est sans danger.

dans le dépôt, vous appuyez sur le type:

git config receive.denyCurrentBranch ignore

cela vous permettra de changer le dépôt tant qu'il s'agit d'une copie de travail.

après avoir exécuté une poussée Git, allez à la machine distante et tapez ceci:

git checkout -f

cela fera les changements vous poussé être reflété dans la copie de travail de la machine distante.

s'il vous plaît noter, ce n'est pas toujours sûr si vous faites des changements sur la copie de travail que vous poussez.

vous pouvez recréer votre dépôt serveur et le pousser de votre maître de branche local au maître de serveur.

sur votre serveur distant:

mkdir myrepo.git
cd myrepo.git
git init --bare

OK, de votre succursale locale:

git push origin master:master

avec quelques étapes de configuration, vous pouvez facilement déployer des changements à votre site Web en utilisant un one-liner comme

git push production

qui est agréable et simple, et vous n'avez pas à vous connecter dans le 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 de travail! (Le PO fonctionnait dans un contexte légèrement différent, et je pense que la solution de @Robert Gould l'a bien abordé. Cette solution est plus appropriée pour déploiement d'un serveur distant.)

tout d'abord, vous devez configurer un dépôt nu quelque part sur votre serveur, en dehors de votre webroot.

mkdir mywebsite.git
cd mywebsite.git
git init --bare

puis créer 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 git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

prêt! Maintenant dans le futur vous pouvez utiliser git push production pour déployer vos modifications!

le crédit pour cette solution va à http://sebduggan.com/blog/deploy-your-website-changes-using-git / . Regardez là pour une explication plus détaillée de ce qui se passe.

Ce que vous n'avez probablement à la cause:

ce genre de chose arrive quand on va à un petit programme. Vous êtes sur le point de changer quelque chose qui fonctionnait déjà, alors vous avez lancé votre sort de niveau 3 d'invisibilité perpétuelle:

machine1:~/proj1> git init

et vous commencez à ajouter/commettre. Mais puis , le projet commence à s'impliquer davantage et vous souhaitez travailler à partir d'un autre ordinateur (comme votre ordinateur personnel ou ordinateur portable), donc vous faites quelque chose comme

machine2:~> git clone ssh://machine1/~/proj1

et il clone et tout semble bon, et donc vous travaillez sur votre code de machine2.

puis ... vous essayez de pousser vos commits de la machine2, et vous obtenez le message d'avertissement dans le titre.

la raison de ce message est que la git repo que vous avez extraite était en quelque sorte destinée à être utilisée uniquement pour ce dossier sur machine1. Vous pouvez clone d'elle très bien, mais pousser peut causer des problèmes. La façon" correcte "de gérer le code dans deux endroits différents est avec un" nu " repo, comme cela a été suggéré. Un nu-pensions n'est pas conçu pour les travaux en cours dans , il est destiné à coordonner les commits à partir de plusieurs sources. C'est pourquoi la réponse la mieux cotée suggère supprimer tous les fichiers/dossiers autres que le .dossier git après vous git config --bool core.bare true .

Clarifier le top-rated réponse: Beaucoup de commentaires pour cette réponse, dire quelque chose comme "je n'ai pas supprimer le non.git fichiers à partir de la machine1, et j'étais encore en mesure de s'engager à partir de la machine2". C'est le droit. Cependant, ces autres dossiers sont complètement "divorcés" de la git repo, maintenant. Aller essayer git status et vous devriez voir quelque chose comme "fatal: Cette opération doit être exécutée dans un travail d'arbre". Donc, la suggestion de supprimer les fichiers n'est pas si que le commit de machine2 va fonctionner ; c'est pour que vous ne vous trompiez pas et que vous pensiez que git est toujours en train de pister 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 devez-vous vraiment faire?

dépend de combien vous prévoyez de travailler encore sur machine1 et machine2...

si vous avez terminé développer à partir de machine1 et ont déplacé tout votre développement à machine2... il suffit de faire ce que la réponse la mieux cotée suggère: git config --bool core.bare true et puis, optionnellement, supprimer tous les fichiers/dossiers autres que .git à partir de ce dossier, car ils sont sans traces et vraisemblablement causer de la confusion.

si votre travail sur machine2 n'a été qu'une seule fois, et que vous n'avez pas besoin de poursuivre le développement... alors ne vous embêtez pas à faire une pension nue; juste ftp / rsync/scp / etc. vos fichiers de machine*2* sur les fichiers de machine * 1*, commit/push à partir de machine*1*, puis supprimez les fichiers de machine*2*. D'autres ont suggéré de créer une branche, mais je pense que c'est un peu compliqué si vous voulez juste fusionner certains développements que vous avez fait sur une base ponctuelle à partir d'une autre machine.

si vous avez besoin de poursuivre le développement à la fois sur machine1 et machine2... alors vous devez mettre les choses en place correctement. Vous avez besoin de convertissez votre pension en un nu, puis vous devez faire un clone de celui sur machine1 pour vous à travailler dans. Probablement le moyen le plus rapide de faire ceci est de 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 de la pension de proj1 à proj1.git, vous devez mettre à jour cela dans le .fichier git / config sur machine2 . Après cela, vous pouvez valider vos changements de machine2. Enfin, j'essaie de garder mes repos nus dans un endroit central, loin de mes arbres de travail (i.e. ne pas mettre 'proj1.git dans le même dossier parent comme "proj1'). Je vous conseille de faire de même, mais je voulais garder les étapes ci-dessus aussi simple que possible.

vous ne devriez pousser que vers un dépôt nu. Un dépôt nu est un dépôt qui n'a pas de branches vérifiées. Si vous deviez cd à un répertoire de dépôt nu, vous verriez seulement le contenu d'un .répertoire git.

vous avez 3 options

1. Tirez et poussez à nouveau:

   git pull; git push
   

2. Poussez-le dans l'autre branche:

   git push origin master:foo
   

   et le fusionner à distance (soit par git ou pull-request )

   git merge foo
   

3. forcez-la (non recommandé sauf si vous avez changé délibérément commet via rebase ):

   git push origin master -f
   

   si elle est toujours refusée, désactiver denyCurrentBranch sur dépôt à distance:

   git config receive.denyCurrentBranch ignore
   

en fait, régler la télécommande sur une branche non vérifiée est suffisant. Après avoir vérifié votre télécommande dans une autre branche, vous pouvez pousser.

j'ai eu le même problème en utilisant Git pour synchroniser les dépôts sur mon téléphone Android et mon ordinateur portable. La solution pour moi était de faire une traction au lieu d'une poussée, comme @CharlesBailey l'a suggéré.

git push origin master sur le dépôt Android échoue pour moi avec les mêmes messages d'erreur que @hap497 obtenu en raison d'une poussée à une caisse non-barré d'un dépôt + copie de travail.

git pull droid master sur le dépôt d'ordinateur portable et des travaux de copie de travail pour moi. Bien sûr, vous devez avoir déjà exécuté quelque chose comme git remote add droid /media/KINGSTON4GB/notes_repo/ .

anciennes versions de Git utilisées pour permettre des pousses vers la branche actuellement vérifiée d'un dépôt non-nu.

Il s'avère que c'était terriblement confus chose pour permettre. Ils ont donc ajouté le message d'avertissement que vous voyez, qui est aussi terriblement confus.

si le premier dépôt agit simplement en tant que serveur, convertissez-le en un dépôt nu comme les autres réponses le recommandent et faites avec.

Si toutefois vous avez besoin pour avoir une branche partagée entre deux repos qui sont tous les deux en usage, vous pouvez le réaliser avec la configuration suivante

Repo1-servira de serveur et sera également utilisé pour le développement

Repo2 - sera pour le développement seulement

Setup Repo1 comme suit

créer une branche pour partager le travail.

git branch shared_branch

pour être sûr, vous devez aussi créer un $(REPO).git / hooks/update qui rejette changements à autre chose que shared_branch, parce que vous ne voulez pas que les gens foutent avec vos branches privées.

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname=""
oldrev=""
newrev=""

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éer une branche locale dans repo1 où vous ferez votre travail réel.

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 nécessiter 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 point vous avez à la fois repo1 et repo2 setup pour travailler sur local les branches qui poussent et tirent de shared_branch dans repo1, sans avoir besoin de se soucier de ce message d'erreur ou d'avoir le répertoire de travail se désynchronisent dans repo1. Quel que soit le flux de travail normal que vous utilisez, il devrait fonctionner.

voici un test que vous pouvez faire pour voir comment fonctionne le serveur bare :

Imaginez que vous ayez une station de travail et un serveur avec un site hébergé en direct, et que vous voulez mettre à jour ce site de temps en temps (ceci s'applique également à une situation où deux développeurs envoient leurs travaux de part et d'autre par un simple intermédiaire).

initialisation

créez un répertoire sur votre ordinateur local et cd dans lui, puis exécuter ces commandes:

# initialization
git init --bare server/.git
git clone server content
git clone server local

1. vous créez D'abord un répertoire server (notez le .git à la fin). Ce répertoire servira de conteneur pour votre référentiel de fichiers uniquement.
2. puis clonez votre dépôt serveur dans un répertoire content nouvellement créé. C'est votre répertoire live/production qui sera servi par votre logiciel serveur.
3. Les deux premiers dossiers se trouvent sur votre serveur, le troisième est un répertoire local sur votre poste de travail.

Flux de travail

voici maintenant le flux de travail de base:

1. entrez dans le répertoire local , créez des fichiers et propagez-les. Enfin les pousser vers le serveur:

   # create crazy stuff
   git commit -av
   git push origin master
   

2. entrez maintenant dans le répertoire content et mettez à jour le contenu du serveur:

   git pull
   

3. répétez 1-2. Ici content peut être un autre développeur qui peut pousser sur le serveur aussi, et local que vous pouvez tirer de lui.

OK, si vous voulez un dépôt distant normal, créez une branche supplémentaire et vérifiez. Poussez - la dans une branche (qui n'est pas cochée) et fusionnez-la avec une branche qui est actuellement active plus tard après avoir poussé à partir de 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

j'ai dû relancer git --init dans un dépôt nu existant, et cela a créé un répertoire .git dans l'arborescence du dépôt nu-j'ai réalisé qu'après avoir tapé git status là. J'ai supprimé et que tout allait bien à nouveau :)

(toutes ces réponses sont grandes, mais dans mon cas c'était quelque chose de complètement différent (autant que je peux voir), comme décrit.)

je suis sûr que la plupart des gens qui verront cette question s'arrêteront aux deux premières réponses énormes, mais je voudrais quand même offrir ma solution.

j'ai eu une configuration de projet web Eclipse + EGit en rencontrant l'erreur décrite. Ce qui m'a aidé était simplement d'utiliser L'application GitHub, qui semblait résoudre magiquement le problème. Alors Qu'EGit refusait toujours la pression, L'application de bureau GitHub haussait les épaules et poussait mes changements. Peut - être qu'il gère la multi-login-situation avec plus de grâce.

un article que j'ai trouvé qui pourrait être utile à d'autres est Git en 5 minutes .

j'ai eu un projet Xcode sous le contrôle de la version Git que j'ai voulu pousser jusqu'à un Ethernet distribué virtuel (VDE) que j'ai dans un DC. Le VDE s'exécute Centos 5.

aucun des articles que j'ai lus sur Git ne parlait de dépôts nus. Tout semblait si simple jusqu'à ce que j'essaie ce que je pensais être facile venant d'un arrière-plan SVN .

les suggestions ici pour rendre le dépôt à distance nu ont fonctionné. Encore mieux pour mes exigences était de cloner le projet Xcode à projectname.git , copier que sur le serveur distant; puis Puches magiquement travaillé. La prochaine étape sera D'obtenir Xcode à push sans erreurs sur les commits, mais pour l'instant je suis d'accord le faire à partir du Terminal.

:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

pour pousser les changements de votre projet Xcode après que vous vous êtes engagé dans Xcode:

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

je suis certain qu'il y a une façon plus sophistiquée de faire ce qui précède, mais à tout le moins cela fonctionne. Juste pour que tout soit clair, voici quelques précisions: /xcode-project-directory est le répertoire dans lequel votre projet xcode est stocké. C'est probablement /Users/Your_Name/Documents/Project_Name . projectname est littéralement le nom de le projet, mais il peut être tout ce que vous avez à vous appeler. Git s'en fiche, tu le feras.

pour utiliser scp vous devez avoir un compte d'utilisateur sur le serveur distant qui est autorisé SSH accès. Quiconque utilise son propre serveur aura ceci. Si vous utilisez un hébergement partagé ou autre, vous n'avez peut-être pas de chance.

remotehost.com est le nom de votre hôte distant. Vous pouvez aussi facilement utiliser son adresse IP. Juste pour plus de clarté j'utilise Gitosis sur l'hôte distant avec les clés SSH, donc je ne suis pas invité à entrer les mots de passe quand je pousse. L'article Hébergement Dépôts Git, le plus Facile (et Sécurisé) vous indique comment régler tout ça.

La meilleure façon de le faire est:

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

cela va cloner le dépôt, mais il ne fera pas de copies de travail dans .../remote . Si vous regardez la télécommande, vous verrez un répertoire créé, appelé currentrepo.git , ce qui est probablement ce que vous voulez.

puis à partir de votre dépôt Git local:

git remote add remoterepo ..../remote/currentrepo.git

après avoir fait des changements, vous pouvez:

git push remoterepo master

je viens de rencontrer ce problème avec un dépôt git de déploiement sur Heroku .

Je ne sais pas pourquoi Heroku a un dépôt non-nu de son côté, mais comme solution de contournement j'ai pu réinitialiser le dépôt distant, et recharger.

vous ne devriez pas utiliser la copie Heroku de votre dépôt comme votre seul dépôt git pour la collaboration, mais juste au cas, je vais dire clairement: ne faites pas cela à moins que vous êtes sûr que vous avoir une copie complète de votre dépôt stocké en toute sécurité ailleurs Qu'Heroku. Une réinitialisation supprimera le contenu du dépôt.

Pour réinitialiser:

0. installez la Heroku toolbelt (qui contient le client en ligne de commande) si vous ne l'avez pas déjà fait.

1. installez le heroku-repo plugin si vous ne l'avez pas déjà.

   heroku plugins:install https://github.com/heroku/heroku-repo.git
   

2. faire la réinitialisation, qui supprime le dépôt et crée un nouveau, vide

   heroku repo:reset
   

3. appuyez sur votre télécommande Heroku comme vous le feriez normalement; elle rechargera tout.

vous devrez changer le fichier de configuration sur le serveur distant une fois que vous aurez créé un dépôt(vide), dites

root@development:/home/git/repository/my-project# cat config 

là vous verrez

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

vous allez faire ceci nu à false à true et j'ai enlevé 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 principale: (inconnu) sera affiché si vous êtes incapable de POUSSER. Donc, si la branche principale est inconnue, vous devriez changer nue en vraie et après push réussi vous pouvez réutiliser le

git remote show origin

et vous verrez

 HEAD branch: master

cochez votre .git/config dans le projet destination:

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

si le core. bare est false, vous pouvez le définir à true:

$ git config core.bare true

et ensuite dans votre push local à distance:

git push remote_repo   // suppose the destination repo is remote_repo

il va réussir, dans le remote_repo vous pouvez vérifier la version git.

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
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 ça devrait remettre bare.bare à false.

$ git config core.bare false

pour moi la solution de travail est:

ON REMOTE:

git checkout -b some_tmp_name

ON LOCAL:

git push

ON REMOTE:

git checkout master
git branch -d some_tmp_name

mais ce n'est pas la vraie solution.

avec Git, deux dépôts réguliers (non-nus) ne peuvent pas pousser/tirer des fichiers directement. Il doit y avoir un dépôt libre intermédiaire. Apparemment, c'est comme un couple marié qui a un enfant, et le couple divorce. Les parents ne se parleront pas, mais ils communiqueront par l'enfant.

Donc, vous avez un dépôt, vous pouvez cloner le dépôt d'un dépôt nu, et puis vous clone que pour un tiers. La première et la troisième peut échanger des informations via le second dépôt, le simple. Je suppose que cela a du sens, car vous ne voudriez pas que quelqu'un puisse vérifier des choses dans votre dépôt sans votre consentement, car cela pourrait causer des conflits de fusion et autres.

donc, voici un exemple:

Sur le PC, dans ~/espace de travail

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

sur ordinateur portable, dans l'espace de travail (ne pas faire de bruit, etc.)

git clone //LJZ-DELLPC/remote-repository.git/ .

// Puis faire de diverses s'engage, et les pousser:

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push    

puis retour sur PC, dans l'espace de travail

git pull

// Puis faire de diverses s'engage, et les pousser:

git push

sur ordinateur portable git pull

et ainsi de suite..

voici un exemple tout à fait concret sur une seule machine, copié directement depuis la fenêtre de commande, pour que nous sachions qu'aucune marche n'a été laissée de côté, que cela a vraiment fonctionné, etc:

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote

Juste au cas où quelqu'un le trouve utile. Pour moi, c'était un serveur git problème d'autorisations. J'ai vérifié le projet à partir de la mise en train et j'ai poussé un fichier simple et puis j'ai eu le "Push rejeté: Push à l'origine / master a été rejeté"

utiliser ceci pour le pousser vers la branche distante en amont a résolu ce problème pour moi:

git push <remote> master:origin/master

la télécommande n'avait pas accès à la remontée amont, donc c'était un bon moyen d'obtenir les derniers changements dans cette télécommande

Ma solution (en cours d'utilisation)

1. Checkout "maître" sur le serveur distant
2. travailler localement sur " dev "branch
3. Pousser des modifications à distance dev
4. Fusion dev en maître sur la télécommande

bingo