Git-Push-Fehler '[Remote abgelehnt] Master -> Master (Zweig ist derzeit ausgecheckt)'

Gestern habe ich eine Frage zum Klonen eines Git- Repositorys von einem meiner Computer auf einen anderen gestellt. Wie kann ich einen Git-Klon von einem anderen Computer erstellen? .

Ich kann jetzt erfolgreich ein Git-Repository von meiner Quelle (192.168.1.2) an mein Ziel (192.168.1.1) klonen.

Wenn ich jedoch eine Datei a git commit -a -m "test"und a bearbeitet git pushhabe, wird an meinem Ziel (192.168.1.1) der folgende Fehler angezeigt:

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'

Ich verwende zwei verschiedene Versionen von Git (1.7 auf der Fernbedienung und 1.5 auf dem lokalen Computer). Ist das ein möglicher Grund?

Sie können Ihr Remote-Repository einfach in ein Bare-Repository konvertieren (es gibt keine Arbeitskopie im Bare-Repository - der Ordner enthält nur die tatsächlichen Repository-Daten).

Führen Sie den folgenden Befehl in Ihrem Remote-Repository-Ordner aus:

git config --bool core.bare true

Löschen Sie dann alle Dateien außer .gitin diesem Ordner. Und dann können Sie git pushfehlerfrei mit dem Remote-Repository arbeiten.

Ich hatte gerade den gleichen Fehler, als ich anfing, Git zu lernen . Einige der anderen Antworten sind eindeutig nicht für jemanden, der neu bei Git ist!

(Ich werde nicht technische Begriffe verwenden, um die Idee zu vermitteln.) Wie auch immer, es passiert, dass Sie zwei Repositories haben, eines ist das Original, das Sie zuerst erstellt haben, und das andere die Arbeit, die Sie gerade erstellt haben.

Im Moment befinden Sie sich in Ihrem Arbeitsrepository und verwenden den Zweig "Master". Sie sind aber auch in Ihrem ursprünglichen Repository bei demselben "Master" -Zweig "angemeldet". Jetzt, da Sie im Original "eingeloggt" sind, befürchtet Git, dass Sie es vermasseln könnten, weil Sie möglicherweise am Original arbeiten und Dinge vermasseln. Sie müssen also zum ursprünglichen Repository zurückkehren und einen "Git Checkout Someotherbranch" durchführen, und jetzt können Sie ohne Probleme pushen.

Ich hoffe das hilft.

Die Fehlermeldung beschreibt, was passiert ist. Moderne Versionen von Git lehnen es ab, einen Zweig per Push zu aktualisieren, wenn dieser Zweig ausgecheckt ist.

Der einfachste Weg, zwischen zwei nicht nackten Repositorys zu arbeiten, ist entweder

1. Aktualisieren Sie die Repositorys immer durch Ziehen (oder Abrufen und Zusammenführen) oder, falls erforderlich, durch

2. indem Sie zu einem separaten Zweig (einem Importzweig) wechseln und diesen Zweig dann mit dem Hauptzweig auf dem Remotecomputer zusammenführen.

Der Grund für diese Einschränkung ist, dass die Push-Operation nur im Remote-Git-Repository ausgeführt wird und keinen Zugriff auf den Index und den Arbeitsbaum hat. Wenn dies zulässig ist, würde ein Push auf den ausgecheckten Zweig ändern HEAD , dass er nicht mit dem Index und dem Arbeitsbaum im Remote-Repository übereinstimmt.

Dies würde es sehr einfach machen, versehentlich eine Änderung festzuschreiben, die alle vorgezogenen Änderungen rückgängig macht, und es auch sehr schwierig machen, zwischen nicht festgeschriebenen lokalen Änderungen und Unterschieden zwischen der neuen HEAD, dem Index und dem Arbeitsbaum zu unterscheiden verursacht durch Druckbewegung HEAD.

Zusammenfassung

Sie können nicht zu dem ausgecheckten Zweig eines Repositorys wechseln, da dies den Benutzer dieses Repositorys auf eine Weise verwirren würde, die höchstwahrscheinlich mit dem Verlust von Daten und Verlauf endet . Sie können jedoch auf jeden anderen Zweig desselben Repositorys pushen.

Da bei Bare-Repositorys niemals ein Zweig ausgecheckt ist, können Sie jederzeit auf einen beliebigen Zweig eines Bare-Repositorys pushen.

Abhängig von Ihren Anforderungen gibt es mehrere Lösungen.

Lösung 1: Verwenden Sie ein nacktes Repostiory

Wenn Sie auf einem Computer das Arbeitsverzeichnis nicht benötigen, können Sie wie vorgeschlagen in ein nacktes Repository wechseln. Um ein Durcheinander mit dem Repository zu vermeiden, können Sie es einfach klonen:

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

Jetzt können Sie alles, was Sie wollen, an dieselbe Adresse wie zuvor senden.

Lösung 2: Drücken Sie zu einem nicht ausgecheckten Zweig

Wenn Sie jedoch den Code auf Ihrer Fernbedienung überprüfen müssen, <remote>können Sie einen speziellen Zweig zum Pushen verwenden. Angenommen, Sie haben in Ihrem lokalen Repository Ihre Fernbedienung angerufen originund befinden sich auf dem Zweigstellenmaster. Dann könntest du es tun

machine2$ git push origin master:master+machine2

Dann müssen Sie es zusammenführen, wenn Sie sich im originRemote-Repo befinden:

machine1$ git merge master+machine2

Autopsie des Problems

Wenn ein Zweig ausgecheckt ist, fügt das Festschreiben ein neues Festschreiben mit dem Kopf des aktuellen Zweigs als übergeordnetem Element hinzu und verschiebt den Kopf des Zweigs zu diesem neuen Festschreiben.

Damit

A ← B
    ↑
[HEAD,branch1]

wird

A ← B ← C
        ↑
    [HEAD,branch1]

Aber wenn jemand dazwischen zu diesem Zweig pushen könnte, würde sich der Benutzer in den Modus bringen , den Git als Detached Head- Modus bezeichnet:

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

Jetzt befindet sich der Benutzer nicht mehr in Zweig1, ohne explizit aufgefordert worden zu sein, einen anderen Zweig auszuchecken. Schlimmer noch, der Benutzer befindet sich jetzt außerhalb eines Zweigs , und jedes neue Commit wird nur baumeln :

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

Wenn der Benutzer zu diesem Zeitpunkt einen anderen Zweig auscheckt, wird dieses baumelnde Commit hypothetisch zu einem fairen Spiel für Gits Garbage Collector .

Sie können diese "Einschränkung" umgehen, indem Sie die .git/configauf dem Zielserver bearbeiten . Fügen Sie Folgendes hinzu, damit ein Git-Repository auch dann verschoben werden kann, wenn es "ausgecheckt" ist:

[receive]
denyCurrentBranch = warn

oder

[receive]
denyCurrentBranch = false

Der erste erlaubt den Push, während er vor der Möglichkeit warnt, den Zweig durcheinander zu bringen, während der zweite ihn nur leise zulässt.

Dies kann verwendet werden, um Code auf einem Server "bereitzustellen", der nicht zum Bearbeiten vorgesehen ist. Dies ist nicht der beste Ansatz, aber ein schneller für die Bereitstellung von Code.

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Verwenden Sie dies im Server-Repository, und es aktualisiert auch den Arbeitsbaum, wenn kein nicht verfolgtes Überschreiben auftreten würde.

Es wurde in Git 2.3 hinzugefügt, wie von VonC erwähnt in den Kommentaren erwähnt.

Ich habe Git 2.3 kompiliert und ausprobiert. Beispielnutzung:

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

Ausgabe:

a
b

Yay, bwurde geschubst!

Ich mag die Idee, immer noch ein verwendbares Repository auf der Remote-Box zu haben, aber anstelle eines Dummy-Zweigs verwende ich gerne:

git checkout --detach

Dies scheint eine sehr neue Funktion von Git zu sein - ich verwende Git Version 1.7.7.4.

Ich hatte das gleiche Problem. Für mich verwende ich Git Push, um Code auf meine Server zu verschieben. Ich ändere niemals den Code auf der Serverseite, daher ist dies sicher.

Im Repository geben Sie Folgendes ein:

git config receive.denyCurrentBranch ignore

Auf diese Weise können Sie das Repository ändern, während es sich um eine Arbeitskopie handelt.

Nachdem Sie einen Git-Push ausgeführt haben, gehen Sie zum Remote-Computer und geben Sie Folgendes ein:

git checkout -f

Dadurch werden die von Ihnen vorgenommenen Änderungen in der Arbeitskopie des Remotecomputers wiedergegeben.

Bitte beachten Sie, dass dies nicht immer sicher ist, wenn Sie Änderungen an der Arbeitskopie vornehmen, auf die Sie zugreifen.

Sie können Ihr Server-Repository neu erstellen und von Ihrem lokalen Zweigstellenmaster auf den Servermaster übertragen.

Auf Ihrem Remote-Server:

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

OK, von Ihrer lokalen Niederlassung:

git push origin master:master

Was Sie wahrscheinlich getan haben, um dies zu verursachen:

So etwas passiert, wenn Sie ein kleines Programm herausholen. Du bist dabei, etwas zu ändern, das bereits funktioniert hat, also sprichst du deinen Level-3-Zauber der fortwährenden Rückgängigmachung:

machine1:~/proj1> git init

und Sie beginnen mit dem Hinzufügen / Festschreiben. Aber dann wird das Projekt immer engagierter und Sie möchten von einem anderen Computer (wie Ihrem Heim-PC oder Laptop) aus daran arbeiten, also machen Sie so etwas

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

und es klont und alles sieht gut aus, und so arbeiten Sie an Ihrem Code von machine2.

Dann ... versuchen Sie, Ihre Commits von machine2 zu übertragen, und Sie erhalten die Warnmeldung im Titel.

Der Grund für diese Nachricht ist, dass das Git-Repo, aus dem Sie gezogen haben, nur für diesen Ordner auf Maschine1 verwendet werden sollte. Sie können ganz gut davon klonen , aber das Drücken kann Probleme verursachen. Die "richtige" Art, den Code an zwei verschiedenen Orten zu verwalten, ist ein "nacktes" Repo, wie vorgeschlagen wurde. Eine nackte Repo ist keine Arbeit entwickelt haben getan in es ist gemeint , die Commits aus mehreren Quellen zu koordinieren. Aus diesem Grund schlägt die am besten bewertete Antwort vor, alle Dateien / Ordner außer dem .git-Ordner nach Ihnen zu löschengit config --bool core.bare true .

Klärung der am besten bewerteten Antwort: Viele der Kommentare zu dieser Antwort lauten etwa "Ich habe die Nicht-Git-Dateien nicht von Maschine1 gelöscht und konnte sie immer noch von Maschine2 festschreiben". Das stimmt. Diese anderen Dateien sind jedoch jetzt vollständig vom Git-Repo "getrennt". Versuchen Sie es git statusdort und Sie sollten etwas wie "fatal: Dieser Vorgang muss in einem Arbeitsbaum ausgeführt werden" sehen. Der Vorschlag, die Dateien zu löschen, ist also nicht so, dass das Festschreiben von machine2 funktioniert . Es ist so, dass Sie nicht verwirrt werden und denken, dass Git diese Dateien immer noch verfolgt. Das Löschen der Dateien ist jedoch ein Problem, wenn Sie dennoch an den Dateien auf Maschine1 arbeiten möchten, nicht wahr?

Also, was solltest du wirklich tun?

Hängt davon ab, wie viel Sie noch an Maschine1 und Maschine2 arbeiten möchten ...

Wenn Sie mit der Entwicklung von Maschine1 fertig sind und Ihre gesamte Entwicklung auf Maschine2 verschoben haben, tun Sie einfach, was die am besten bewertete Antwort vorschlägt: git config --bool core.bare trueLöschen Sie dann optional alle Dateien / Ordner außer .git aus diesem Ordner, da diese sind nicht verfolgt und verursachen wahrscheinlich Verwirrung.

Wenn Ihre Arbeit an machine2 nur eine einmalige Sache war und Sie dort nicht weiterentwickeln müssen ... dann machen Sie sich nicht die Mühe, ein nacktes Repo zu machen. nur ftp / rsync / scp / etc. Ihre Dateien von Maschine * 2 * über die Dateien auf Maschine * 1 *, Commit / Push von Maschine * 1 * und Löschen der Dateien von Maschine * 2 *. Andere haben vorgeschlagen, einen Zweig zu erstellen, aber ich denke, das ist etwas chaotisch, wenn Sie nur eine Entwicklung zusammenführen möchten, die Sie einmalig von einem anderen Computer aus durchgeführt haben.

Wenn Sie die Entwicklung sowohl auf Maschine1 als auch auf Maschine2 fortsetzen möchten , müssen Sie die Dinge richtig einrichten. Sie müssen Ihr Repo in ein Bare konvertieren und dann einen Klon davon auf Maschine1 erstellen, damit Sie darin arbeiten können . Der wahrscheinlich schnellste Weg, dies zu tun, ist dies

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

Sehr wichtig: Da Sie den Speicherort des Repos von proj1 nach proj1.git verschoben haben, müssen Sie dies in der .git / config-Datei auf machine2 aktualisieren . Danach können Sie Ihre Änderungen von machine2 aus festschreiben. Zuletzt versuche ich, meine nackten Repos an einem zentralen Ort fern von meinen Arbeitsbäumen zu halten (dh 'proj1.git' nicht im selben übergeordneten Ordner wie 'proj1' ablegen). Ich rate Ihnen, dies ebenfalls zu tun, aber ich wollte die obigen Schritte so einfach wie möglich halten.

Mit ein paar Einrichtungsschritten können Sie Änderungen auf Ihrer Website einfach mithilfe eines Einzeilers wie bereitstellen

git push production

Das ist nett und einfach, und Sie müssen sich nicht beim Remote-Server anmelden und einen Pull ausführen oder so. Beachten Sie, dass dies am besten funktioniert, wenn Sie Ihre Produktionskasse nicht als Arbeitszweig verwenden! (Das OP arbeitete in einem etwas anderen Kontext, und ich denke, die Lösung von @Robert Gould hat es gut angegangen. Diese Lösung eignet sich besser für die Bereitstellung auf einem Remote-Server.)

Zuerst müssen Sie irgendwo auf Ihrem Server außerhalb Ihrer Webroot ein nacktes Repository einrichten.

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

Dann Datei erstellen hooks/post-receive:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

Und machen Sie die Datei ausführbar:

chmod +x hooks/post-receive

Auf Ihrem lokalen Computer

git remote add production [email protected]:mywebsite.git
git push production +master:refs/heads/master

Alles bereit! Jetzt in der Zukunft können Sie git push productionIhre Änderungen bereitstellen!

Das Guthaben für diese Lösung finden Sie unter http://sebduggan.com/blog/deploy-your-website-changes-using-git/ . Dort finden Sie eine detailliertere Erklärung der Vorgänge.

Sie sollten nur auf ein nacktes Repository pushen. Ein nacktes Repository ist ein Repository ohne ausgecheckte Zweige. Wenn Sie in ein nacktes Repository-Verzeichnis cd würden, würden Sie nur den Inhalt eines .git-Verzeichnisses sehen.

Sie haben 3 Möglichkeiten

1. Ziehen und erneut drücken:

   git pull; git push
   

2. In einen anderen Zweig schieben:

   git push origin master:foo
   

   und führen Sie es auf Remote (entweder per gitoder Pull-Anfrage ) zusammen

   git merge foo
   

3. Erzwingen Sie es (nicht empfohlen, es sei denn, Sie haben die Commits absichtlich über geändert rebase):

   git push origin master -f
   

   Wenn dies immer noch abgelehnt wird, deaktivieren Sie es denyCurrentBranch im Remote-Repository:

   git config receive.denyCurrentBranch ignore
   

In der Tat ist es ausreichend, die Fernbedienung auf einen nicht ausgecheckten Zweig einzustellen. Nachdem Sie Ihre Fernbedienung in einem anderen Zweig ausgecheckt haben, können Sie pushen.

Überprüfen Sie Ihre .git/configim Zielprojekt:

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

Wenn das core. barefalsch ist, können Sie es auf true setzen:

$ git config core.bare true

und dann in Ihrem lokalen Push auf Remote:

git push remote_repo   // suppose the destination repo is remote_repo

es wird erfolgreich sein, in remote_repo können Sie die git-Version überprüfen.

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < [email protected]>
Date:   Thu May 17 21:54:37 2018 +0800

und jetzt können Sie git nicht in Ihrem "Arbeitsbereich" verwenden:

$ git status
fatal: This operation must be run in a work tree

Sie sollten bare.bareauf false zurücksetzen.

$ git config core.bare false

Ich hatte das gleiche Problem mit Git, um Repositorys auf meinem Android-Handy und Laptop zu synchronisieren. Die Lösung für mich war, einen Zug statt eines Stoßes zu machen, wie @CharlesBailey vorschlug.

git push origin master auf dem Android-Repository schlägt für mich mit den gleichen Fehlermeldungen fehl, die @ hap497 aufgrund eines Pushs zu einem nicht bloßen Auschecken eines Repositorys + einer Arbeitskopie erhalten hat.

git pull droid masterauf dem Laptop-Repository und Arbeitskopie funktioniert für mich. Natürlich müssen Sie vorher so etwas ausgeführt haben git remote add droid /media/KINGSTON4GB/notes_repo/.

Ältere Versionen von Git ermöglichten Pushs in den aktuell ausgecheckten Zweig eines nicht nackten Repositorys.

Es stellte sich heraus, dass dies eine schrecklich verwirrende Sache war. Also haben sie die Warnmeldung hinzugefügt, die Sie sehen, was auch schrecklich verwirrend ist.

Wenn das erste Repository nur als Server fungiert, konvertieren Sie es in ein nacktes Repository, wie in den anderen Antworten empfohlen, und erledigen Sie es.

Wenn Sie jedoch einen gemeinsamen Zweig zwischen zwei Repos benötigen, die beide verwendet werden, können Sie dies mit dem folgenden Setup erreichen

Repo1 - fungiert als Server und wird auch für die Entwicklung verwendet

Repo2 - ist nur für die Entwicklung bestimmt

Richten Sie Repo1 wie folgt ein

Erstellen Sie einen Zweig, an dem Sie Ihre Arbeit teilen können.

git branch shared_branch

Um sicher zu gehen, sollten Sie auch ein $ (REPO) .git / hooks / update erstellen, das alle Änderungen an etwas anderem als shared_branch ablehnt, da Sie nicht möchten, dass Leute mit Ihren privaten Filialen herumspielen.

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

Erstellen Sie nun in repo1 eine lokale Niederlassung, in der Sie Ihre eigentliche Arbeit erledigen.

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'

(muss möglicherweise, git config --global push.default upstreamum git pushzu arbeiten)

Jetzt können Sie repo2 mit erstellen

git clone path/to/repo1 repo2 
git checkout shared_branch 

Zu diesem Zeitpunkt müssen Sie sowohl repo1 als auch repo2 für lokale Zweige shared_brancheinrichten, die in repo1 pushen und ziehen , ohne sich um diese Fehlermeldung kümmern zu müssen oder das Arbeitsverzeichnis in repo1 nicht mehr synchron zu haben. Welchen normalen Workflow Sie auch verwenden, er sollte funktionieren.

OK, falls Sie ein normales Remote-Repository möchten, erstellen Sie einen zusätzlichen Zweig und checken Sie ihn aus. Schieben Sie es in einen Zweig (der nicht ausgecheckt ist) und führen Sie ihn mit einem Zweig zusammen, der später aktiv ist, nachdem Sie ihn lokal verschoben haben.

Zum Beispiel auf einem Remote-Server:

git branch dev
git checkout dev

Auf dem lokalen Setup:

git push 

Auf dem Remote-Server:

git merge dev

Hier ist ein Test, den Sie durchführen können, um zu sehen, wie das bareServermaterial funktioniert:

Stellen Sie sich vor, Sie haben eine Workstation und einen Server mit einer darauf gehosteten Live-Site und möchten diese Site von Zeit zu Zeit aktualisieren (dies gilt auch für Situationen, in denen zwei Entwickler ihre Arbeit über einen bloßen Mittelsmann hin und her senden).

Initialisierung

Erstellen Sie ein Verzeichnis auf Ihrem lokalen Computer und führen cdSie die folgenden Befehle aus:

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

1. Zuerst erstellen Sie ein nacktes serverVerzeichnis (beachten Sie die .git am Ende). Dieses Verzeichnis dient nur als Container für Ihre Repository-Dateien.
2. Klonen Sie dann Ihr Server-Repository in ein neu erstelltes contentVerzeichnis. Dies ist Ihr Live- / Produktionsverzeichnis, das von Ihrer Serversoftware bereitgestellt wird.
3. Die ersten beiden Verzeichnisse befinden sich auf Ihrem Server, das dritte ist ein lokales Verzeichnis auf Ihrer Workstation.

Arbeitsablauf

Hier ist der grundlegende Workflow:

1. Geben Sie das localVerzeichnis ein, erstellen Sie einige Dateien und schreiben Sie sie fest. Schieben Sie sie schließlich auf den Server:

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

2. Geben Sie nun das contentVerzeichnis ein und aktualisieren Sie den Inhalt des Servers:

   git pull
   

3. Wiederholen Sie 1-2. Hier contentkann ein anderer Entwickler sein, der auch auf den Server pushen kann, und localwie Sie von ihm ziehen können.

Dies zu verwenden, um es an den Remote-Upstream-Zweig zu senden, löste dieses Problem für mich:

git push <remote> master:origin/master

Die Fernbedienung hatte keinen Zugriff auf das Upstream-Repo, daher war dies eine gute Möglichkeit, die neuesten Änderungen an dieser Fernbedienung vorzunehmen

Ich musste git --initin einem vorhandenen Bare-Repository erneut ausgeführt werden, und dies hatte ein .gitVerzeichnis innerhalb des Bare-Repository-Baums erstellt - das wurde mir nach der Eingabe git statusdort klar . Ich habe das gelöscht und alles war wieder in Ordnung :)

(Alle diese Antworten sind großartig, aber in meinem Fall war es etwas völlig anderes (soweit ich sehen kann), wie beschrieben.)

Ich bin sicher, dass die meisten Leute, die diese Frage sehen, bei den ersten beiden großen Antworten aufhören werden, aber ich möchte trotzdem meine Lösung anbieten.

Ich hatte ein Eclipse + EGit-Webprojekt eingerichtet, als der beschriebene Fehler auftrat. Was mir geholfen hat, war einfach die Verwendung der GitHub-App, die das Problem auf magische Weise zu lösen schien. Während EGit den Push immer ablehnte, zuckte die GitHub-Desktop-App nur mit den Schultern und drückte meine Änderungen. Vielleicht geht es mit der Multi-Login-Situation eleganter um.

Ein Artikel, den ich für andere nützlich finden könnte, ist Git in 5 Minuten .

Ich hatte ein Xcode- Projekt unter Git-Versionskontrolle, das ich auf ein Virtual Distributed Ethernet (VDE) übertragen wollte, das ich in einem DC habe. Auf dem VDE wird Centos 5 ausgeführt.

Keiner der Artikel, die ich über Git gelesen habe, sprach von nackten Repositories. Es klang alles so einfach, bis ich versuchte, was ich für einfach hielt, wenn ich von einem SVN- Hintergrund kam.

Die Vorschläge hier, um das Remote-Repository freizulegen, haben funktioniert. Noch besser für meine Anforderungen war es, das Xcode-Projekt zu klonen und projectname.gitauf den Remote-Server zu kopieren. dann drückt magisch gearbeitet. Der nächste Schritt wird darin bestehen, Xcode ohne Fehler über Commits zu pushen, aber im Moment bin ich damit einverstanden, dies vom Terminal aus zu tun.

Damit:

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/>

So übertragen Sie Änderungen aus Ihrem Xcode-Projekt, nachdem Sie Xcode festgeschrieben haben:

cd /xcode-project-directory<br/>
git push [email protected]:repos/projectname.git<br/>

Ich bin mir sicher, dass es eine reibungslosere und raffiniertere Methode gibt, aber zumindest funktioniert dies. Damit alles klar ist, hier einige Klarstellungen: /xcode-project-directoryIst das Verzeichnis, in dem Ihr xcode-Projekt gespeichert ist. Es ist wahrscheinlich /Users/Your_Name/Documents/Project_Name. Projektname ist buchstäblich der Name des Projekts, aber es kann alles sein, was Sie nennen möchten. Git ist das egal.

Um scp verwenden zu können, benötigen Sie ein Benutzerkonto auf dem Remote-Server, das den SSH- Zugriff ermöglicht. Jeder, der seinen eigenen Server betreibt, hat dies. Wenn Sie Shared Hosting oder ähnliches verwenden, haben Sie möglicherweise kein Glück.

remotehost.comist der Name Ihres Remote-Hosts. Sie können auch die IP-Adresse verwenden. Aus Gründen der Übersichtlichkeit verwende ich Gitosis auf dem Remote-Host mit SSH-Schlüsseln, sodass ich beim Drücken nicht zur Eingabe von Kennwörtern aufgefordert werde. Der Artikel Hosting von Git-Repositorys auf einfache (und sichere) Weise erklärt Ihnen, wie Sie all das einrichten.

Der beste Weg, dies zu tun, ist:

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

Dadurch wird das Repository geklont, es werden jedoch keine Arbeitskopien erstellt .../remote. Wenn Sie sich die Fernbedienung ansehen, wird ein Verzeichnis mit dem Namen erstellt currentrepo.git, das wahrscheinlich das ist, was Sie möchten.

Dann aus Ihrem lokalen Git-Repository:

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

Nachdem Sie Änderungen vorgenommen haben, können Sie:

git push remoterepo master

Ich bin gerade auf dieses Problem mit einem Deployment-Git-Repository auf Heroku gestoßen .

Ich weiß nicht, warum Heroku ein nicht nacktes Repository auf seiner Seite hat, aber als Problemumgehung konnte ich das Remote-Repository zurücksetzen und erneut hochladen.

Sie sollten Herokus Kopie Ihres Repositorys nicht als Ihr einziges Git-Repository für die Zusammenarbeit verwenden, aber für alle Fälle sage ich klar: Tun Sie dies nur, wenn Sie sicher sind, dass Sie eine vollständige Kopie Ihres Repositorys sicher an einem anderen Ort als gespeichert haben Heroku. Durch einen Reset wird der Repository-Inhalt gelöscht.

Zurücksetzen:

0. Installieren Sie den Heroku-Toolbelt (der den Befehlszeilenclient enthält), falls Sie dies noch nicht getan haben.

1. Installieren Sie das Heroku-Repo-Plugin, falls Sie dies noch nicht getan haben.

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

2. Führen Sie den Reset durch, wodurch das Repository gelöscht und ein neues, leeres erstellt wird

   heroku repo:reset
   

3. Drücken Sie wie gewohnt auf Ihre Heroku-Fernbedienung. es wird alles neu hochladen.

Sie müssen die Konfigurationsdatei auf dem Remote-Server ändern, nachdem Sie beispielsweise ein leeres (nacktes) Repository erstellt haben

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

dort wirst du sehen

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

Sie werden dies bloß von falsch zu wahr machen und ich habe logallrefupdates = true entfernt (nicht sicher, ob es verwendet wird!)

zu

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

Sie können Folgendes testen

$ 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)

Dieser HEAD-Zweig: (unbekannt) wird angezeigt, wenn Sie nicht DRÜCKEN können. Wenn der HEAD-Zweig nicht bekannt ist, sollten Sie bare in true ändern und nach erfolgreichem Push können Sie den wiederverwenden

git remote show origin

und du wirst sehen

 HEAD branch: master

Für mich ist die Arbeitslösung:

AUF FERNBEDIENUNG:

git checkout -b some_tmp_name

ON LOCAL:

git push

AUF FERNBEDIENUNG:

git checkout master
git branch -d some_tmp_name

Dies ist jedoch nicht die eigentliche Lösung, sondern nur eine Problemumgehung.

Nur für den Fall, dass jemand es nützlich findet. Für mich war es ein Problem mit den Git-Server-Berechtigungen. Ich habe das Projekt von Anfang an ausgecheckt und eine einfache Datei gepusht und dann die Meldung "Push abgelehnt: Push to Origin / Master wurde abgelehnt" erhalten.

Mit Git können zwei reguläre (nicht nackte) Repositorys Dateien nicht direkt hin und her verschieben. Es muss ein zwischengeschaltetes nacktes Repository vorhanden sein. Anscheinend ist es wie bei einem Ehepaar, das ein Kind hat, und das Paar lässt sich scheiden. Die Eltern werden nicht miteinander reden, aber sie werden durch das Kind kommunizieren.

Wenn Sie also ein Repository haben, klonen Sie dieses Repository in ein nacktes Repository und klonen es dann in ein drittes. Das erste und das dritte können Informationen über das zweite Repository austauschen, das bloße. Ich denke, dies ist sinnvoll, da Sie nicht möchten, dass jemand ohne Ihre Zustimmung Inhalte in Ihr Repository einchecken kann, da dies zu Zusammenführungskonflikten und dergleichen führen kann.

Hier ist ein Beispiel:

Auf dem PC in ~ / workspace

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

Auf dem Laptop in ~ / workspace (git init usw. nicht ausführen)

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

// Dann mache verschiedene Commits und drücke sie:

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

Dann zurück auf dem PC in ~ / workspace

git pull

// Dann mache verschiedene Commits und drücke sie:

git push

Auf Laptop Git ziehen

und so weiter..

Hier ist ein absolut konkretes Beispiel auf einem Computer, das direkt aus dem Befehlsfenster kopiert wurde, damit wir wissen, dass keine Schritte ausgelassen wurden, dass es wirklich funktioniert hat usw.:

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

Meine Lösung (in Gebrauch)

1. Kasse "Master" auf Remote-Server
2. Arbeiten Sie lokal am Zweig "dev"
3. Änderungen an Remote-Entwickler übertragen
4. Führen Sie dev in master on remote ein

Bingo