ubuntuusers.de

Problem mit git und push

Status: Gelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |

gbauer81

Anmeldungsdatum:
30. November 2006

Beiträge: 633

Wohnort: Landau / Pfalz

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?

fred.reichbier

Anmeldungsdatum:
14. Dezember 2006

Beiträge: 350

Hallo,

wie sah dein git add - Aufruf aus? Was sagt git status

Gruß Fred

gbauer81

(Themenstarter)

Anmeldungsdatum:
30. November 2006

Beiträge: 633

Wohnort: Landau / Pfalz

Mein git status sagt

# On branch master
# (use "git reset HEAD <file>..." to unstage)
#
#

Die Datei text2.txt sollte eigentlich dem Repository durch den push Befehl hinzugefügt werden.
Mein Aufruf sieht zur Zeit wie folgt aus:

mkdir git_test
cd git_test
mkdir git1_rep
cd git1_rep
git init
echo "Ich bin eine Textdatei" > text.txt
git add text.txt
git commit -m "Initialisierung"
cd ..
git clone git1_rep git2_rep
cd git2_rep
echo "Ich bin noch eine Textdatei" > text2.txt
git add text2.txt
git commit -m "Zweite Textdatei"
git push

Lunar

Anmeldungsdatum:
17. März 2006

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.

gbauer81

(Themenstarter)

Anmeldungsdatum:
30. November 2006

Beiträge: 633

Wohnort: Landau / Pfalz

Lunar hat geschrieben:

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.

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?

Lunar

Anmeldungsdatum:
17. März 2006

Beiträge: 5792

gbauer81 hat geschrieben:

Was ist ein Bare Repositorie?

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#def_bare_repository

gbauer81 hat geschrieben:

Gibt es eine Möglichkeit, damit er dies direkt so übernimmt, ohne das man nochmals zusätzlich git checkout -f ausführt?

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.

gbauer81

(Themenstarter)

Anmeldungsdatum:
30. November 2006

Beiträge: 633

Wohnort: Landau / Pfalz

Also,
ich erkläre einfach halber mal die Situation. Vielleicht kann man dann einen besseren Tipp geben wie man dies am besten mit git realisieren kann.

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.

Lunar

Anmeldungsdatum:
17. März 2006

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!

gbauer81

(Themenstarter)

Anmeldungsdatum:
30. November 2006

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.

Antworten |