Git als Versionskontrollsystem - Anfänger hat Fragen

Hallo!

Ich möchte gern Git als VCS benutzen und habe Probleme damit. Ich kenne bereits SVN und habe auch schon damit gearbeitet und vielleicht auch deswegen leichte Umstellungsprobleme.

Hier meine Fragen:

1.Ich erstelle ein Repo(git init), füge eine Datei hinzu und committe. Alles klar, lokaler Commit, richtig? Jetzt git push und schon ist es auf meinem zentralen Git-Server. Jetzt lösche ich einfach mal via Explorer die gerade hinzugefügte Datei. Was aber wenn ich die Datei zurück haben möchte? Revert? Checkout oder Pull? Das ist mir nicht ganz so klar.

2.Wenn ich die Datei übr den Explorer lösche und dann das Repo Committe, ist die Datei dann auch aus dem Repo verschwunden? Oder uss ich git sagen: Diese Datei aus dem Repo löschen.

3.Bei SVN ist es so, wenn ich committe, aber ein anderer User berets committed hat, soll ich erst ein Update ausführen, vergleichen und dann committen? Ist das bei git genau das Gleiche?

4.Was ist das genau equivalent von SVN's update bei git? Geht auch in die Frage 1 ein.

5.Was genau ist rebase bei git?

So...ich hoffe die Fragen sind klar, ich freue mich auf Antworten.

Vielen DAnk!

Cybertec

Kauf dir ein Buch!

rüdiger

1. Mit git reset --hard HEAD kannst du deinen Tree wieder auf die aktuelle Version zurück setzen. Für einzelne Dateien kannst du aber auch git checkout dateiname nehmen. git revert ist dafür da, wenn du einen commit rückgängig machen willst. Push ist davor gar nicht nötig, da du ja lokal eine History hast. Pull ist das gleiche wie fetch/merge. Zieht also die Änderungen aus einem anderen Repo.

http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html

2. Du musst die Datei natürlich auch in git löschen ( git rm )

3. Wenn du pushst und deine Änderungen zu einem Konflikt führen würden, dann musst du den lokal beheben. Also in etwa das gleiche.

4. Kommt drauf an. In der Regel wohl git pull

http://git.or.cz/course/svn.html

5. Mit rebase kannst du die History manipulieren.

http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

nman

jensen8229 schrieb:

Jetzt lösche ich einfach mal via Explorer die gerade hinzugefügte Datei. Was aber wenn ich die Datei zurück haben möchte? Revert? Checkout oder Pull? Das ist mir nicht ganz so klar.

git checkout dateiname

Mit revert kannst du Commits durch einen Umkehr-Commit rueckgaengig machen und mit pull holst du dir frische Commits aus einem anderen Repo.

2.Wenn ich die Datei übr den Explorer lösche und dann das Repo Committe, ist die Datei dann auch aus dem Repo verschwunden? Oder uss ich git sagen: Diese Datei aus dem Repo löschen.

Nein, die ist normalerweise auch aus dem Repo drauszen. Die Versionsgeschichte der Datei bleibt aber natuerlich da.

3.Bei SVN ist es so, wenn ich committe, aber ein anderer User berets committed hat, soll ich erst ein Update ausführen, vergleichen und dann committen? Ist das bei git genau das Gleiche?

Im wesentlichen schon, ja.

4.Was ist das genau equivalent von SVN's update bei git? Geht auch in die Frage 1 ein.

git pull

5.Was genau ist rebase bei git?

Noch ein bisschen zu kompliziert fuer dich, lass davon mal die Finger.

Lies mal hier rein, dann kennst du dich besser aus:
http://progit.org/book/

nman

rüdiger schrieb:

2. Du musst die Datei natürlich auch in git löschen ( git rm )

OP: Damit die unterschiedlichen Antworten nicht verwirren: Kommt primaer darauf an, wie du commitest. So braucht man zB. kein git rm :

rm foo
git commit -a

zwutz

jensen8229 schrieb:

Was aber wenn ich die Datei zurück haben möchte? Revert? Checkout oder Pull? Das ist mir nicht ganz so klar.

gibt unterschiedliche Wege. Der einfachste wär aber ein checkout. Du brauchst dazu nur einen Branch, wo die Datei noch vorhanden ist, dann kannst du sie einfach auschecken (git checkout <branch> <datei>)

jensen8229 schrieb:

2.Wenn ich die Datei übr den Explorer lösche und dann das Repo Committe, ist die Datei dann auch aus dem Repo verschwunden? Oder uss ich git sagen: Diese Datei aus dem Repo löschen.

das ist analog zu Dateiänderungen, nur, dass du nicht git add, sondern git rm verwendest. Also ja, du musst sie explizit aus dem repo löschen. Dafür sparst du dir das löschen aus dem explorer, weil das git übernimmt

jensen8229 schrieb:

3.Bei SVN ist es so, wenn ich committe, aber ein anderer User berets committed hat, soll ich erst ein Update ausführen, vergleichen und dann committen? Ist das bei git genau das Gleiche?

ja. Das passiert aber nur, wenn ihr beide am gleichen Branch arbeitet. Sobald jeder seine eigenen Branches verwendet, tritt das eher selten auf. Wobei auch in deinem Fall der Aufwand eher gering ist. Du wirst nur dazu aufgefordert, vorm push den aktuellen Stand vom Server zu holen. Erst wenn das mergen der beiden Stände nicht konfliktfrei war, musst du selbst Hand anlegen

jensen8229 schrieb:

4.Was ist das genau equivalent von SVN's update bei git? Geht auch in die Frage 1 ein.

git pull

jensen8229 schrieb:

5.Was genau ist rebase bei git?

etwas, das du nie verwenden solltest, es sei denn, du weißt, dass du es verwenden kannst

Es nimmt den aktuellen Branch, erstellt ihn vom master neu und wendet die Änderungen des Branches erneut an. Kann vor allem dann böse enden, wenn jemand anderes diesen Branch auch verwendet. Für genauere Infos siehe bitte die entsprechende man-page. Habs selbst noch nie verwendet.
Ich kann mir ehrlich gesagt auch kein Szenario vorstellen, wo das sinnvoll wäre

Ich rate dir aber auch, entsprechende Tutorials anzusehen. Einerseits um die übliche Arbeitsabfolge reinzubringen, andererseits, um die teils netten Features kennenzulernen, die dir im Fall des Falles die Haut retten können

nman

zwutz schrieb:

Ich kann mir ehrlich gesagt auch kein Szenario vorstellen, wo das sinnvoll wäre

Oh, rebase ist oft sinnvoll. Ganz besonders die interaktive Variante, bei der man noch Commits reparieren und zusammensquashen kann, bevor man sie veroeffentlicht. Damit lassen sich dann auch ungebremst ganz furchtbar miese Sachen committen, die man so nicht veroeffentlichen moechte. Und Commit-Serien wie "+300/-299/+4" zu einem huebschen "+5"-Commit aufraeumen.

Aber Anfaenger sollten davon auf alle Faelle die Finger lassen.

zwutz

nman schrieb:

Und Commit-Serien wie "+300/-299/+4" zu einem huebschen "+5"-Commit aufraeumen.

ein Praxisbeispiel wär besser
Aber ich glaub dir

Skeptiker schrieb:

So ziemlich jeder, mit dem ich ueber Git gesprochen hatte, hatte Probleme bei der Bedienung von Git. Und das IST ein Designflaw.
Vor allem nicht IT Mitarbeiter blicken bei dem ganzen commit/push/pull/revert Null durch. Git ist nur theoretisch gut, in der Praxis stinkt es gewaltig.

nicht it-mitarbeiter brauchen auch nicht alle Funktionen, wenn sie git überhaupt brauchen.
Seit wir auf git umgestiegen sind, sind wir weit stressfreier unterwegs und auch schneller bei den Releases. Und das ist es, was zählt.

nman

zwutz schrieb:

nman schrieb:

Und Commit-Serien wie "+300/-299/+4" zu einem huebschen "+5"-Commit aufraeumen.

ein Praxisbeispiel wär besser

Das ist zwar vielleicht ein kleines bisschen uebertrieben, aber ich schreibe oft zig Zeilen Code dahin ohne mich irgendwie ums Aufraeumen zu kuemmern. Aufraeumen bremst mich beim Denken viel zu sehr ein, das kann ich nachher immer noch machen.

Natuerlich moechte ich waehrend dieser Zeit nicht auf Versionskontrolle verzichten, also committe ich weiterhin haeufig. Nur dass mein kreatives Chaos oeffentlich verewigt wird und andere Leute verwirrt, moechte ich nicht. Daher das Aufraeumen samt rebase -i vor dem Veroeffentlichen.

Wenn ich fertig bin, kann es schonmal vorkommen, dass ich zwar zweihundert Zeilen Code geaendert habe, davon aber nur mehr ein huebscher Commit mit +30 Zeilen uebrigbleibt.

zwutz

ah ok, ich versteh worauf du hinaus willst. Gut, den Einwand lass ich gelten :p

Vielen Dank für die Antworten. Ihr habt mir geholfen. Ich werde mich an das probook halten um noch zu erfahren.

Vielen DANK!!!

Cybertec schrieb:

Kauf dir ein Buch!

Warum ist git so kompliziert, dass man ein Buch dazu braucht?

pumuckl

igit schrieb:

Cybertec schrieb:

Kauf dir ein Buch!

Warum ist git so kompliziert, dass man ein Buch dazu braucht?

Braucht man nur, wenn man alle Features ausnutzen will, weils einfach recht viel zu bieten hat. Die Grundfunktionalität ist mit 4 Seiten Tutorial/Doku schnell gelernt.

DrGreenthumb

nman schrieb:

4.Was ist das genau equivalent von SVN's update bei git?

git pull

5.Was genau ist rebase bei git?

Noch ein bisschen zu kompliziert fuer dich, lass davon mal die Finger.

git pull ist nicht das Äquivalent. Damit werden ständig merge-commits erzeugt und die gitk-Ausgabe bekommt extrem viele Parallel-Linien.

Deswegen statt git push IMMER:

`

git fetch

git rebase origin/master

(nochmal testen :-P)

git push

`

(spricht was dagegen?)

... Das mache ich so schon einige Zeit, ohne zu wissen, wofür "rebase" eigentlich steht. Ein Buch zu lesen ist hoffentlich keine Voraussetzung.

Cybertec

pumuckl schrieb:

igit schrieb:

Cybertec schrieb:

Kauf dir ein Buch!

Warum ist git so kompliziert, dass man ein Buch dazu braucht?

Braucht man nur, wenn man alle Features ausnutzen will, weils einfach recht viel zu bieten hat. Die Grundfunktionalität ist mit 4 Seiten Tutorial/Doku schnell gelernt.

Jo, genau.

Wenn du nur die Grundfunktionalitäten wissen willst -> https://github.com/esc/git-cheatsheet-de

nman

DrGreenthumb schrieb:

Deswegen statt git push IMMER:

`

git fetch

git rebase origin/master

(nochmal testen :-P)

git push

`

(spricht was dagegen?)

Ja, die Existenz von git pull --rebase .

Nein, im Ernst: Genau das ist einer der häufigsten Anwendungszwecke von rebase, aber als Anfänger würde ich von rebase erstmal die Finger lassen, bis ich verstanden habe, wie das funktioniert.

Falls dich interessiert, was rebase macht - auch wenn der von dir beschriebene Fall weitgehend unproblematisch ist:
git-rebase(1) erklärt das ganz gut.
Und http://progit.org/book/ch3-6.html erklärt es nochmal besser.

nman

nman schrieb:

Ja, die Existenz von git pull --rebase .

Wobei ich eigentlich fast immer Feature Branches verwende, die kann man auch rebasen. Häufig möchte man das aber gar nicht, sondern gibt sogar beim merge an, dass ein Merge-Commit erzeugt werden soll und kein Fast Forward gemacht werden soll.

Damit ist es nämlich dann auch ziemlich trivial, Merges von Feature Branches wieder rückgängig zu machen.

Ich bin weder "merge für alles"- noch "rebase für alles"-Verfechter. Beides hat seine Daseinsberechtigung.

DrGreenthumb

nman schrieb:

Ja, die Existenz von git pull --rebase .

ah, das habe ich schonmal gesehen aber wurde abgeschreckt von der unsympathischen Warnung in der manpage:

Note
This is a potentially dangerous mode of operation. It rewrites
history, which does not bode well when you published that
history already. Do not use this option unless you have read
git-rebase(1) carefully.

wenn ich git fetch; git rebase mache, wird doch aber keine bereits gepublishte history umgeschrieben?!

"git-rebase(1) carefully lesen" klingt jedenfalls nicht nett...

nman schrieb:

Nein, im Ernst: Genau das ist einer der häufigsten Anwendungszwecke von rebase, aber als Anfänger würde ich von rebase erstmal die Finger lassen, bis ich verstanden habe, wie das funktioniert.

Falls dich interessiert, was rebase macht - auch wenn der von dir beschriebene Fall weitgehend unproblematisch ist:
git-rebase(1) erklärt das ganz gut.
Und http://progit.org/book/ch3-6.html erklärt es nochmal besser.
...
Wobei ich eigentlich fast immer Feature Branches verwende ...
Damit ist es nämlich dann auch ziemlich trivial, Merges von Feature Branches wieder rückgängig zu machen.

Danke, das Buch steht auch auf meiner todo-Liste
Was rebase in meinem Beispiel macht, weiß ich hoffentlich: ungepushte commits rückgängig -> pull -> commits wieder drauf.
Unterschied zu pull --rebase?

"Feature Branch" heißt alle lokalen commits mit "squash" zu einem zusammenfassen??
Kommt man dann später noch an die ursprünglichen commits oder landen die nicht im repository?

nman

DrGreenthumb schrieb:

ah, das habe ich schonmal gesehen aber wurde abgeschreckt von der unsympathischen Warnung in der manpage:

Note
This is a potentially dangerous mode of operation. It rewrites
history, which does not bode well when you published that
history already. Do not use this option unless you have read
git-rebase(1) carefully.

Daher ja auch meine Empfehlung, als Anfaenger ohne Ahnung kein rebase zu verwenden.

wenn ich git fetch; git rebase mache, wird doch aber keine bereits gepublishte history umgeschrieben?!

Das kommt ganz auf deinen Workflow an. Wenn du zu Remote A pusht und dann ein fetch und ein rebase von B machst, dann schon. Wenn du nur ein oeffentliches Remote-Repo hast, dann vermutlich nicht.

"git-rebase(1) carefully lesen" klingt jedenfalls nicht nett...

Es geht alles nur darum, dass du keine Commits manipulieren solltest, die bereits veroeffentlicht wurden, weil du nicht anderen Leuten die Geschichte unter dem Hintern wegschieszen moechtest.

Was rebase in meinem Beispiel macht, weiß ich hoffentlich: ungepushte commits rückgängig -> pull -> commits wieder drauf.
Unterschied zu pull --rebase?

Gar keiner. "git pull --rebase" macht genau das.

"Feature Branch" heißt alle lokalen commits mit "squash" zu einem zusammenfassen??
Kommt man dann später noch an die ursprünglichen commits oder landen die nicht im repository?

Nein, das heiszt, dass ich fuer jedes groeszere Feature eine komplett neue Branch von master abzweige und saemtliche Arbeiten an diesem Feature nur dort mache. Wenn ich damit fertig bin, merge ich entweder diese Branch zu master, oder ich rebase sie dorthin.

Zusammengesquasht werden in der Regel nur ueberfluessige Commits zum Aufraeumen. Wenn ich drei Commits zu einem zusammensquashe, dann landet ja nur der eine Commit in der Versionsgeschichte, das moechte man nicht immer.

Schoen zu sehen, wie hier saemtliche Git kritischen Kommentare einfach geloescht werden! Wenn eine Meinung nicht zu der der Mods passt, wird sie wohl geloescht. Tolles Forum!