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


961

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                                                
hap@192.168.1.2'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://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/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?


5
Kann ein Oldtimer die akzeptierte Antwort auf stackoverflow.com/a/9283833/397872 ändern und den Thread in das Archiv verschieben oder so? Oder den Besitzer wechseln oder was auch immer?
Rishta

9
Sie haben jetzt tatsächlich eine sichere Möglichkeit, mit Git 2.3.0 (Februar 2015) und git config receive.denyCurrentBranch=updateInstead: stackoverflow.com/a/28262104/6309
VonC

Das ist der neue Link des Buches, das @stigi erwähnt hat: git-scm.com/book/en/v1/Git-on-the-Server
Abdelilah El Aissaoui


Aber ich verstehe nicht warum und wie es funktioniert? Es funktioniert, ja, aber das ist alles.
Tilak Maddy

Antworten:


1149

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.


4
Vielen Dank. Ich brauchte das auch. Ich folgte dem Tutorial für Submodule aus dem Git Community Book und traf diese Straßensperre.
Shiki

6
Ich war mir nicht sicher, ob Sie Dateien auf dem Server oder auf dem Client löschen wollten ... also habe ich nichts gelöscht, und das Problem verschwindet, nachdem ich es getan habe git config --bool core.bare true. Gibt es einen bestimmten Grund, warum einige Dateien gelöscht werden müssen? Wenn ja, können Sie genauer sagen, was gelöscht werden muss?
Brian Vandenberg

24
Es ist die bestmögliche Antwort und niemand anderes hat sie im Loch Interwebs bereitgestellt. Ich denke, wir haben alle die gleiche Fehlermeldung gegoogelt und wir waren alle sehr glücklich, dies zu lesen.
Sebastián Grignoli

40
Obwohl es viele Stimmen bekommen hat, denke ich nicht, dass dies eine wirklich angemessene Antwort auf diese spezielle Frage ist. Es wäre halb so schlimm, den Benutzer anzuweisen, wie man ein nacktes Repo sauber erstellt, aber was ist, wenn die Dateien ausgecheckt bleiben müssen, beispielsweise wenn es sich um das Repository handelt, mit dem der Benutzer auf zwei Computern arbeitet?
Nirgendwo Mann

9
Das Ändern des Quell-Repos in "Bare" ist übertrieben. Alles, was Sie tun müssen, ist, in einen neuen Zweig im Quell-Repo zu pushen, wie @Robert hervorhebt: stackoverflow.com/a/2933656/402949 .
Dan Solovay

708

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.


76
+1 Viel hilfreicher, danke Robert. Ich hatte in meinem Fall keinen Sinn, auf ein nacktes Repo umzusteigen. Sie müssen lediglich den Zweig deaktivieren, zu dem Sie einen Push durchführen möchten. Macht Sinn.
Eric Muyser

32
@ FMaz008: Erstellen Sie einfach einen Dummy-Zweig (Git Checkout -b Dummy)
Dror Cohen

14
Mann, das ist weitaus besser als die meisten Antworten :) Danke. Obwohl die andere Antwort auch gut aussagt :)
Ivan Ivanić

103
Um dies klarer zu machen, ist dies im Repo das Ziel des Pushs : git checkout -b tmp. Dann im Quell-Repo : git push. Dann zurück ins Ziel (optional):git checkout master; git branch -d tmp
Hari Karam Singh

18
Haris Kommentar ist das einfachste Rezept. Ich muss nur sagen, dass Git in vielerlei Hinsicht großartig sein kann und von svn oder wahrscheinlich von anderen rvs kommt, aber das Ganze ist erstaunlich nicht intuitiv.
UnconditionallyReinstateMonica

128

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.


1
Vielen Dank. Wie kann ich mein Problem beheben? In meiner 192-Box habe ich '$ cd (Projektverzeichnis) $ git init $ (einige Dateien hinzufügen) $ git add'. und dann habe ich in meiner 191-Box einen 'Git-Klon' gemacht und einige Dateien bearbeitet und dann versucht, 'Git-Push' zu machen.
Hap497

16
Nun, ich habe die Möglichkeiten in meiner Antwort beschrieben. Entweder können Sie zur 192-Box gehen und von der 191-Box abrufen (möglicherweise möchten Sie die 191-Box als benannte Fernbedienung hinzufügen - siehe git remote add box191 <191url>), oder Sie können dann von der 191-Box zu einem alternativ benannten Zweig (z. B. git push origin master:refs/heads/upload) wechseln in die 192 Box und verschmelzen (zB git merge upload).
CB Bailey

3
Sie haben jetzt tatsächlich eine sichere Möglichkeit, mit Git 2.3.0 (Februar 2015) auf ein nicht nacktes Repo zu pushen, und git config receive.denyCurrentBranch=updateInstead: stackoverflow.com/a/28262104/6309 : Sie benötigen Option 2 nicht mehr.
VonC

122

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 .


3
Eine technische Korrektur für "Autopsie": Git wird nicht wirklich HEADin das Push-to-Repository getrennt. HEADzeigt weiterhin auf den Zweig, und der Zweig zeigt wiederum auf die neuen Commits, die gepusht wurden; Das Arbeitsverzeichnis und der Index- / Staging-Bereich bleiben jedoch unverändert. Wer am Push-to-Repository arbeitet, muss jetzt hart arbeiten, um sich von den Auswirkungen des Push zu erholen: Finden Sie heraus, ob Änderungen gespeichert werden müssen, und arrangieren Sie diese gegebenenfalls sorgfältig, um sie zu speichern.
Torek

Um Ihrer Antwort zusätzliche Informationen hinzuzufügen, gibt es nur wenige Gründe, warum Sie möchten, dass ein Remote-Repository, auf das die Benutzer drängen, nicht nackt ist. Daher ist die Verwendung eines nackten Repositorys die beste Lösung.

2
Tatsächlich habe ich viele Situationen gefunden, in denen ich auf ein nicht nacktes Repository pushen muss, und ich verwende die Lösung 2 ziemlich oft. Außerdem ist der Zweig, in dem ich auf das nicht nackte Repository pushe, in keiner Weise ein temporärer Zweig, sondern dient einem ähnlichen Zweck wie ein Remote-Tracking-Zweig.
Nirgendwo Mann

Ich habe auf meinem Server einen GIT-Ordner erstellt, in dem ALLE Repositorys gehostet werden, die von mehreren Benutzern mit SourceTree erstellt wurden. Ich habe masterauf meinem lokalen PC ein Repository erstellt . Ich habe das remoteszum Serverordner hinzugefügt und versucht, mein Repository auf den Server zu verschieben, damit ein anderer Benutzer es abrufen / abrufen kann, um daran zu arbeiten. Ich erhalte die folgende Fehlermeldung: ! [remote rejected] master -> master (branch is currently checked out)Wie kann ich es einchecken?
SearchForKnowledge

1
@SearchForKnowledge, stellen Sie fest, dass Sie genau die Frage stellen, auf die ich antworte?!
Nirgendwo Mann

65

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.


7
Die Verwendung dieser Option zum "Bereitstellen" von Code auf einem Server funktioniert nicht. Selbst wenn Sie die Warnung deaktivieren, damit Sie in den ausgecheckten Zweig pushen können, wird die Arbeitskopie NIEMALS bei einem Push aktualisiert.
Arrowmaster

10
Ich verwende die obige Methode mit cd .. && git reset --hardPost-Receive-Hook zum Bereitstellen. Hackisch, funktioniert aber.
Jholster

9
die Kommandozeilenversion des letzteren wäregit config receive.denyCurrentBranch warn
Andre Holzner

4
Dies sollte die akzeptierte Antwort sein. Einige von uns wissen, was wir tun und sind keine Git-Anfänger. Dies ist die Antwort für diese Leute.
Qix - MONICA wurde am

2
Ha, aber die Frage war nicht byt fragt diese Menschen.
Nirgendwo Mann

46

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!


@VonC danke! Es ist meine Besessenheit mit minimalen Beispielen bei der Arbeit :-)
Ciro Santilli 法轮功 病毒 审查 六四 六四 法轮功

Hat dies Probleme beim Festschreiben von Änderungen, die mit dem Server nicht auf dem neuesten Stand sind?
Akozi

@akozi Ich bin mir nicht sicher, was du meinst. Wenn du vor dem Ziehen lokal festschreibst, verhält es sich genau wie ein traditioneller --bareKlon, den ich denke: Er --forcemuss pushen, und du wirst Commits auf der Fernbedienung "verlieren".
Ciro Santilli 法轮功 病毒 审查 六四 事件 24

1
@CiroSantilli 新疆 改造 中心 六四 六四 法轮功 Keine Sorge jetzt. Ich habe die Bedeutung der Optionen nachgeschlagen. Ich dachte, dass updateInstead gleichbedeutend mit Gewalt ist.
Akozi

updateInstead ist kein gültiger Wert mehr für receive.denyCurrentBranch
Xalorous

41

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.


8
Nachdem Sie Ihre Änderungen vorgenommen haben, können Sie Folgendes verwenden git checkout master:, um zum Hauptzweig zurückzukehren. Erst dann werden Ihre Änderungen übernommen.
MAZDAK

30

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.


Dank eines Protokolls füge ich Ihren Vorschlag zusammen denyCurrentBranchund lege ihn git checkout -fin einen hooksOrdner wie @ jack-senechal, der hier veröffentlicht wurde
Éderson T. Szlachta,

Gibt es eine Möglichkeit, die Dateien im Remote-Repository anzuzeigen, ohne diesen Befehl aufzurufen? Nämlich durch einen Befehl von der lokalen?
Royi

24

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

3
Vielen Dank, dies war die Lösung für mich, da ich '--bare' auf dem Remote-Server weggelassen hatte. Es scheint, dass die Antworten auf diese Frage davon abhängen, ob Sie das Remote-Server-Repo als Arbeitsverzeichnis verwenden oder nicht. Für den späteren Fall ist dies die richtige Antwort.
Cas

2
Ich verstehe nicht: SI hat versucht, ein nacktes Repo zu erstellen und zu klonen, aber der Klon hat nichts heruntergeladen und nichts hochgeladen, also funktioniert das nicht ... :-) Ich habe Tutorials über nackte Repos gelesen, aber sie sagen, dass es ein nacktes Repo ist enthält keine Dateien ... Das ist definitiv nicht das, wonach ich suche ...
inf3rno

22

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.


Sehr detailliert und hilfreich. Mein Fall war der letzte, und Ihre Anweisungen wirkten wie ein Zauber.
Pojda

Ich bin in Fall 3 und habe etwas anderes gemacht: mk git-server; mv .git git-server / proj.git und dann git klonen git-server / proj.git auf 1 und 2 (oder git remote origin ...) unter Verwendung eines geeigneten ssh: // Präfixes für Maschine 2. Auf diese Weise Ich werde eine bloße Masterkopie behalten, die der normalen auf GH oder einem anderen HTTP-Server entspricht, und ich werde weiterhin Push / Pull auf beiden Computern verwenden.
Zakmck

18

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 git@myserver.com: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.


Ihr Vorschlag hat mir sehr geholfen, aber ich habe ihn nicht verwendet bare. Ich folge diesem und verschmelze mit hooks(den Sie vorgeschlagen haben) und habe perfekt funktioniert.
Éderson T. Szlachta

11

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.


9
Es ist nichts Falsches daran, in einen nicht ausgecheckten Zweig in einem nicht nackten Repository zu wechseln. Dies ist eine absolut gültige Arbeitsweise.
CB Bailey

Fair genug, das würde funktionieren. Aber das ist nicht das, was der Benutzer tut.
RibaldEddie

13
Es ist nicht die Tatsache, dass er kein nacktes Repository verwendet, das "falsch" ist; es ist die Tatsache, dass er zu einer ausgecheckten Filiale drängt. Es gibt keine Beweise dafür, dass er ein separates nacktes Repository hat oder will. Ihre pauschale Aussage, dass er nur in ein nicht nacktes Repository pushen sollte, gibt dem Fragesteller nicht alle Optionen. einer davon könnte sein unmittelbares Problem leichter lösen.
CB Bailey

10

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
    

Option 2 funktioniert für mich. Remote Git Init Local Git Push Ursprung Master: Zweig Remote Git Merge DONE
Jacky Chong

7

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.


7

Ü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 < aircraft_xxx@126.com>
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

5

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


4

Ä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.


3

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

2

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.


2

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


1
Allgemeiner (da dies der Nettoeffekt des Befehls ist), mit git push <remote> master:newbranch. Die Idee ist, dass Sie einen neuen Zweig auf die Fernbedienung übertragen, der dann zusammengeführt werden kann. Auf diese Weise vermeiden Sie alle in der Fehlermeldung genannten Inkonsistenzprobleme.
Clay

1

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


1

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.


1

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 sshusername@remotehost.com:repos/<br/>

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

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com: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.


1

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

1

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:

  1. Installieren Sie den Heroku-Toolbelt (der den Befehlszeilenclient enthält), falls Sie dies noch nicht getan haben.
  2. Installieren Sie das Heroku-Repo-Plugin, falls Sie dies noch nicht getan haben.

    heroku plugins:install https://github.com/heroku/heroku-repo.git
    
  3. Führen Sie den Reset durch, wodurch das Repository gelöscht und ein neues, leeres erstellt wird

    heroku repo:reset
    
  4. Drücken Sie wie gewohnt auf Ihre Heroku-Fernbedienung. es wird alles neu hochladen.


Möglicherweise müssen Sie die Heroku-Repo-Tools installieren, damit dies funktioniert. Doheroku plugins:install https://github.com/heroku/heroku-repo.git
Noah

1

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

0

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.


Dies ist eine gültige Lösung, wenn Sie kein zentrales Repository haben.
Rick

0

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.


-1

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

Es ist ein Beispiel dafür, was funktioniert, und eine Erklärung, warum. Es gibt hier überhaupt keine Fehlinformationen, außer Ihrem Kommentar.
Lyle Z

1
"Mit Git können zwei reguläre (nicht nackte) Repositorys Dateien nicht direkt hin- und herschieben" - außer dass sie dies können.
Andrew C

Gut, poste ein konkretes Beispiel anstelle eines Angriffs.
Lyle Z

Oder könnten Sie es googeln? stackoverflow.com/questions/1764380/…
Andrew C

Die erste Antwort in dem Thread, den Sie auf Ihrer Website erstellen, beginnt mit "... aber laut git ready und dem offiziellen git-Wiki sollten Sie nur auf ein nacktes Repo drängen." In der nächsten Antwort heißt es: "Wenn Sie versuchen möchten, nur master -> master zu drücken, lautet der Befehl einfach: git push origin", und das funktioniert einfach nicht, und es gibt zig Postings zu diesem Effekt. Die letzte Antwort beginnt mit "Ich würde vorschlagen, ein Bare-Repository und ein lokales funktionierendes (nicht Bare) Repos auf Ihrem Server zu haben.", Genau das habe ich vorgeschlagen.
Lyle Z

-3

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

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.