2010-08-19 3 views
1

Après avoir pensé que je me suis enfin débrouillé, je me retrouve maintenant très confus au sujet d'un comportement de git que je vois - chaque fois que je pousse les changements faits et validés sur ma machine locale jusqu'à mon dépôt git d'origine, ces changements immédiatement mis en scène pour être annulé sur le serveur d'origine. Huh ??!?Pourquoi mon origine git veut-elle supprimer tous mes changements poussés?

J'ai une machine (machine A) avec un dépôt git dessus pour un projet; cette machine exécute un serveur SSH et j'ai configuré un compte pour pouvoir me connecter à distance et cloner le repo git. J'ai ensuite utilisé git sur la machine B pour cloner le repo:

git clone ssh://[email protected]/path/to/repo

sans problème. J'apporté des modifications au projet sur la machine B, et engage ces changements dans le dépôt git sur B. Ensuite, je poussais les modifications dans le référentiel d'origine sur la machine A:

git push master origin

et qui a bien fonctionné; sur la machine B, la sortie de git remote show origin montre que l'origine est à ce jour:

$ git remote show origin 
* remote origin 
    Fetch URL: ssh://[email protected]/path/to/repo 
    Push URL: ssh://[email protected]/path/to/repo 
    HEAD branch: master 
    Remote branch: 
    master tracked 
    Local ref configured for 'git push': 
    master pushes to master (up to date) 

Mais quand je vais à la machine A et fais git status, je vois que tous les changements que je viens POUSSÉ sont maintenant mis en scène pour être défait!

$ git status 
# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
#  modified: build-fatjar.xml 
#  deleted: src/monitor/config/client-lm-prod.xml 
#  modified: src/monitor/config/quartz-baseconfig.xml 
#  modified: src/monitor/service/task/BaseTask.java 
#  new file: src/monitor/service/task/CheckForCorrections.java 
#  deleted: src/monitor/service/task/CheckForDuplicates.java 
#  deleted: src/monitor/service/task/ProcessCorrections.java 
#  renamed: src/monitor/test/CheckForDuplicatesTest.java -> src/monitor/test/CheckForCorrectionsTest.java 
#  deleted: src/monitor/test/ProcessCorrectionsTest.java 
#  modified: src/monitor/test/TaskTestCase.java 

La seule façon d'obtenir le dépôt d'origine (machine A) au même état que celui sur la machine B est de git reset HEAD pour réinitialiser chacun d'entre eux tous ces changements à être désengagés puis git rm; sinon, le prochain git commit sur la machine A annulera tout ce que je viens de pousser de la machine B.

J'ai lu toutes les références que je peux trouver et je ne mentionne pas ce comportement; De même, je ne peux pas trouver de référence en ligne non plus. Des idées?

+1

Eh bien, il est mentionné assez souvent dans plusieurs questions SO. Voir http://stackoverflow.com/questions/3523008/how-do-i-push-to-the-current-git-branch-on-remote-and-have-changes-reflected-immédiatement et http: // toroid .org/ams/git-website-howto – MvanGeest

Répondre

5

Cela ressemble à pousser vers un dépôt non vide (c'est-à-dire, un repo dont les fichiers sont extraits sur le disque). Git mettra à jour le dépôt, mais pas les fichiers extraits, donc il semblera qu'il ya des changements en attente d'être mis en scène. La solution est de faire l'une des deux choses:

  1. Soit pousser dans une prise en pension nue (origine), puis utiliser un crochet après réception pour vérifier les fichiers (en utilisant peut-être git archive) à un autre endroit sur le serveur, ou
  2. Utilisez un hook post-réception pour exécuter git checkout ou quelque chose pour mettre à jour les fichiers sur disque.

Vous pouvez en lire plus dans ce Stack Overflow question ou dans ce how-to article.

+0

Fantastique - oui, c'est tout. J'ai mis en place un repo nu sur la machine A plutôt que sur un "régulier", et maintenant tout est fabuleusement fabuleux. – delfuego

0

oui @MvanGeest a raison, vous êtes en train de pousser vers un repo non nu. Si vous avez l'intention d'utiliser un repo comme un «repo béni», c'est-à-dire de la même manière que vous utiliseriez un référentiel maître dans subversion, vous devez créer un repo nu et y pousser. si dans la situation que vous avez maintenant, vous devez entrer dans un et tirer de b.

Questions connexes