Hallo zusammen,
ich spiel zur Zeit ein wenig mit git rum und hab da ein Problem.
Also erstes hab ich mir ein normales git Repository erstellt und dies dann lokal auf der Festplatte geklont. Soweit noch kein problem. Wenn ich nun z. B. neue Dateien in dem zweiten Repository anlege und commit ausführe funktioniert dies problem los. Beim problem liegt nun beim push Befehl, mit dem ich die Änderungen an das Ursprungs Repository übertragen will. Nach dem ausführen der push funktion findet sich im Log meine Änderung im Ursprungs Repository wieder, aber die neue Datei wird nicht im Ursprungs Repository erstellt.
Vorgehensweise bis jetzt ist wie folgt:
1. Verzeichnis erstellen, git init ausführen und Testdatei anlegen.
2. Neues Verzeichnis erstellen und Repository mittels git clone pfad/zu/datei klonen.
3. Im neuen Repository weitere Dateien erstellen / ändern.
4. git add und git commit ausführen und Ändernungen übernehmen.
5. git push ausführen.
Hat jemand nen Tipp was ich hier falsch mache?
Problem mit git und push
Anmeldungsdatum: Beiträge: 633 Wohnort: Landau / Pfalz |
|
Anmeldungsdatum: Beiträge: 350 |
Hallo, wie sah dein Gruß Fred |
(Themenstarter)
Anmeldungsdatum: Beiträge: 633 Wohnort: Landau / Pfalz |
Mein git status sagt
Die Datei text2.txt sollte eigentlich dem Repository durch den push Befehl hinzugefügt werden.
|
Anmeldungsdatum: Beiträge: 5792 |
git push ändert nur die Metadaten, nicht aber die eigentlichen Dateien. Das ist auch nicht der Sinn von push, da es auch mit Bare Repositories arbeiten muss. In deinem Fall sollte ein ``git checkout -f`` im Ursprungsrepository die Lösung bringen. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 633 Wohnort: Landau / Pfalz |
Lunar hat geschrieben:
Was ist ein Bare Repositorie? Gibt es eine Möglichkeit, damit er dies direkt so übernimmt, ohne das man nochmals zusätzlich git checkout -f ausführt? |
Anmeldungsdatum: Beiträge: 5792 |
gbauer81 hat geschrieben:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#def_bare_repository gbauer81 hat geschrieben:
Nicht das ich wüsste. Eigentlich macht das auch keinen Sinn. Öffentliche zentrale Repos, die zur Verteilung der Patches und Commits dienen, sind bare, haben also keinen lokalen Checkout, und zwischen Entwickler Repos wird selten gepusht und gepullt. Und wenn, dann möchte kaum ein Entwickler immer seine lokalen Änderungen verlieren, oder sich plötzlich wieder im master befinden. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 633 Wohnort: Landau / Pfalz |
Also, Auf einem OnlineServer von uns soll ein Repository angelegt werden, in dem der Quellcode zu unserem Projekt liegen soll. Das Projekt soll dann von uns lokal weiterentwickelt werden und die änderungen in das Online Repository übernommen werden. Auf das Repository sollen nur die Entwickler von der Firma zugriff haben. |
Anmeldungsdatum: Beiträge: 5792 |
Und wozu benötigst du da eine automatische Aktualisierung des lokalen Checkouts? Dein Ablauf sieht eher so aus: Mittels ``git clone --bare`` im Ursprungsrepository ein Bare Repository erstellen, und das auf den Server kopieren. Das kannst du dann über ssh oder git veröffentlichen (je nach deinen Anforderungen). Die Entwickler "pushen" ihre Änderungen in dieses Repository, Änderungen können dann per pull explizit geholt werden. Sind Entwickler mit größeren Änderungen beauftragt, sollten diese zusätzlich noch eine eigene Branch anlegen. So sieht ganz grob ein entsprechender Ablauf bei git aus. Im Übrigen ist das bei zentralen VCS nicht anders, bei SVN muss auch explizit ein ``svn update`` durchgeführt werden, um die lokale Kopie zu aktualisieren. Edit: Und ganz ehrlich: Wenn git Teil eines professionellen Entwicklungsablauf werden soll, ist das Benutzerhandbuch eigentlich Pflichtlektüre. Da steht alles drin, was ich dir gesagt habe. Mit dem Wissen aus dieser Konversation kannst du kein öffentliches Git-Repo verwalten! |
(Themenstarter)
Anmeldungsdatum: Beiträge: 633 Wohnort: Landau / Pfalz |
Eine automatische Aktualsierung des lokalen Checkouts brauch ich natürlich nicht, hier kann jeder Entwickler dies selbst veranlassen. Dank dir Lunar, dank deinem groben Arbeitsablauf bekomm ich einen besseren Überblick und versteh so langsam wie das ganze funktioniert. Da hast du natürlich recht das das git Benutzerhandbuch zur Pflichlektüre werden muss. Es gibt nun noch einiges für mich zu lernen, aber vielen Dank für den groben Arbeitsablauf einblick. |