Git als Versionskontrollsystem - Anfänger hat Fragen

[zwutz]

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

[jensen8229]

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

Vielen DANK!!!

[igit]

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.

[DikatorMods?]

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!