Message passé en amont lors du retour à une branche maître vide?
Ma version de git est Git-1.9.4-preview20140611 Auparavant, j'avais cloné un référentiel d'origine git vide. Le référentiel cloné mais avec le message suivant
warning: vous semblez avoir cloné un référentiel vide. Vérification de la connectivité ... fait.
Ensuite, copiez un fichier .gitIgnore qui se trouvait dans le référentiel Git principal d'un autre projet et l'envoyiez au maître local. Ce fichier a été utilisé par nous plusieurs fois auparavant. Cela semble bien. Nous avons un fichier standard .gitIgnore pour tous nos projets. Cela a été créé dans le cadre des meilleures pratiques.
Next a créé une nouvelle branche et copié du code à l'emplacement physique où réside le dépôt git local
git checkout -b FromCC
Ajout du code et engagement dans cette branche.
git add --all
git commit -M "Blah"
Toutes ces opérations sont réussies.
Mon but est de fusionner éventuellement ces modifications dans une branche maître locale.
Je fais ensuite
git checkout master
et recevez le message suivant.
Votre branche est basée sur 'Origine/maître', mais l'amont est parti. (utilisez "git branch --unset-upstream" pour réparer)
Que signifie ce message? Pourquoi en amont "partir"?
Observation intéressante: j'ai répété le même processus avec le même référentiel maître Git aujourd'hui. Cette fois, le référentiel Git n'était pas vide. Il avait le fichier .gitIgnore avant la main. Cette fois, le message mentionné précédemment n'apparaissait pas.
Ce n'est pas le répertoire amont repository (Origin lui-même), mais la branche spécifique que vous avez clonée (master sur Origin) qui manque.
De plus, le message de git est trompeur: la branche master de Origin n'est pas est partie , elle était n'a jamais été là . Lorsque vous avez cloné le référentiel vide, il ne comportait aucune branche. Il a continué à ne pas avoir de branches. Par conséquent, votre master locale, qui était configurée pour suivre Origin/master, suivait (est) une branche qui n'existe pas.
Le message est plus destiné à une situation comme celle-ci:
$ git clone ...
$ git checkout featureX # track some feature branch
[go away for a week, come back]
$ git fetch -p # update remote branches
pendant cette semaine, la branche featureX a été supprimée (probablement intégrée à sa ligne de développement et désormais inutile). À ce stade, vous êtes sur une branche locale, featureX, paramétré pour suivre le Origin/featureX de la branche distante, mais il n'y a plus de Origin/featureX.
Dans ce cas, cependant, vous avez la branche locale master suivi Origin/master quand il n’ya pas Origin/master pour le moment . Une fois que vous l'avez créé (via le Push qui rend le référentiel non vide), le problème disparaîtra. Cela est apparu uniquement parce que par défaut, vous commencez par master même si la télécommande est vide et n'a pas encore de master.
En tant que novice chez git/github, je suis tombé sur cette idée après avoir créé un dépôt complètement vide sur github et git cloned au niveau local. Y compris l'avertissement concernant un dépôt vide. Ensuite, un commit pour un fichier local nouvellement créé a donné le message "En amont est parti".
Ce qui suit suppose que l’on souhaite utiliser le référentiel distant, il serait donc nécessaire de définir l’amont:
J'ai pensé ajouter que ce github a suggéré, lors de la création du repo vide, quelques commandes. Le point critique dans ce cas serait les commandes git Push -u Origin master (après les commandes init, add (pour un fichier), commit et remote add Origin <url>). Cela transfère le maître existant localement vers le dépôt distant github.
Le commutateur -u sur Push définit l’amont (la version longue est --set-upstream) sur l’ensemble sur github. Je dois admettre que le reste de la page de manuel git-Push relative à ce commutateur reste mystique. moi ... Depuis la section locale n'est pas à jour ni poussée avec succès.
Le message a disparu car la branche principale est maintenant disponible sur le référentiel distant.
J'ai eu le même message d'erreur avec github. Le problème, c’est que je n’ai pas approuvé l’invitation au référentiel. Donc, le git a pensé que je n'avais pas les droits pour le repo.