eGit auto pull / push

[freez]

Hallo,

nach dem Tipp von Schalentier probiere ich gerade eGit mit Eclipse helios aus. Ich habe ein zentrales Repo auf einem Netzlaufwerk, welches via Laufwerk "x" verbunden ist. Dann habe ich auf 2 Rechner jeweils ein lokales repo.

Nun ist mir aufgefallen, dass man seine Änderungen (die commits) via push extra fürs zentrale Repo freigeben muss und man hat ggfs. merge Aufwand, wenn man es eine Weile nicht gemacht hat. Ich vermisse ein automatisches push nach einem commit. Dann wäre das zentrale repo immer auf dem aktuellen Stand. Ausserdem wäre es sinnvoll, wenn regelmäßig per pull gegen das zentrale repo geprüft wird.

Kennt ihr eine Möglichkeit, dies mit eGit irgendwie zu lösen?

 

[schalentier]

1. Fang mit git auf der Commandzeile an, das hilft ungemein fuers Verstaendnis. Spaeter kannste dann mit eGit rumspielen.
2. Was du vor hast widerspricht dem Gedanken von GIT. Du willst nicht jeden Commit automatisch pushen. Erst Recht nicht automatisch pullen.
3. Es gibt unter .git/hooks entsprechende Beispiele fuer Hooks, also Skripte, die bei bestimmten Ereignissen (commit, etc) ausgefuehrt werden.

Hier noch ein sehr gutes Tutorial fuer Git: Understanding Git Conceptually

 

[freez]

Danke für die Antwort:

zu 1. habe ich. Und das funktioniert auch ganz gut. Ist nur so ... wenn ich von cvs auf git umstelle, dann müssen meine Teammitglieder mitziehen ... Ich befürchte jetzt schon so Sätze, wie "in cvs ging das aber einfacher" ... und an der Stelle ist es nun mal ein Schritt mehr, an dem auch Probleme auftreten können. Ich habe schon einiges an Verständnis aufgebaut und das war nicht einfach. Es soll ja am besten reibungslos umgestellt werden.
zu 2. Nun, bis jetzt standen im CVS direkt nach einem Commit die Änderungen für alle zur Verfügung. Ich finde das auch ziemlich gut so und bis jetzt hatten wir diesbezüglich nie die Anforderung dies anders zu machen. Also stelle ich mir die Frage, warum ich es hier benötige.
zu 3. Das werde ich mir mal anschauen. Vielleicht ist ja was interessantes dabei

Meine Meinung zu eGit noch kurz:
Das Plugin arbeitet hervorragend, wenn man nur lokal arbeitet. Allerdings ist die Arbeit mit einem zentralen Repo doch etwas verwirrend und das Plugin leitet einen nicht wirklich zur richtigen Arbeitsweise an, sodass man schnell an eine Stelle kommt, wo es nicht weiter geht.
Vor allem, warum habe ich im zentralen Repo alle Branches verfügbar und in meiner lokalen Clone habe ich nur einen einzigen Branch, den "Master". Ich will doch in der Regel einen kompletten Clone des zentralen Repos haben. Ich kann zwar von dem Master wiederum branchen, aber mir fehlen die anderen Branches aus dem zentralen Repo. komisches Verhalten, vor allem, weil ich alle Branches angegeben habe zu fetchen.
Noch ein weiteres Manko des Plugins: Will ich in mein lokales repo pullen übernimmt er in der Regel sauber die Änderungen. Allerdings gibt es Situationen (wahrscheinlich bei Konflikten), da "vergisst" er scheinbar das Mergen und sagt einfach nix. Erst bei genaueren Hinschauen erkennt man, dass sich die Versionen von lokal zu remote unterscheiden. Ein "Merge..." bringt dann ans Tageslicht, dass es konflikte gibt, die ich erst beheben muss. So eine Info könnte ja schon mal kommen und idealerweise auch gleich ein Dialog, der einem dabei hilft.
Ich habe auch noch keine Funktion gefunden, die mir nach einem missglückten Merge meine letzte lokale Version wiederherstellt um das Ganze noch mal gegen das zentrale Repo laufen zu lassen.

Nunja, genug geschimpft

 

[schalentier]

zu 1. habe ich. Und das funktioniert auch ganz gut. Ist nur so ... wenn ich von cvs auf git umstelle, dann müssen meine Teammitglieder mitziehen ... Ich befürchte jetzt schon so Sätze, wie "in cvs ging das aber einfacher" ... und an der Stelle ist es nun mal ein Schritt mehr, an dem auch Probleme auftreten können. Ich habe schon einiges an Verständnis aufgebaut und das war nicht einfach. Es soll ja am besten reibungslos umgestellt werden.

Schon klar, aber rechne damit, dass der besagte Satz kommen wird. Wenn die Teammitglieder keinen Bock auf Git haben, bringt der Umstieg nichts - dann lass es lieber.

zu 2. Nun, bis jetzt standen im CVS direkt nach einem Commit die Änderungen für alle zur Verfügung. Ich finde das auch ziemlich gut so und bis jetzt hatten wir diesbezüglich nie die Anforderung dies anders zu machen. Also stelle ich mir die Frage, warum ich es hier benötige.

Ja, aber Git ist nicht CVS. Mit Git machst du dir einen lokalen Branch in dem du deine aktuelle Aufgabe (neues Feature, Bugfix, etc) bearbeitest ([c]git checkout -b bugfix/1234[/c]). Du kannst (und sollst!) hier oft commiten, meinetwegen auch Fehler - bisher ist alles lokal und du stoerst niemanden damit ([c]git commit[/c]).

Wenn du denkst du bist fertig, kannst du deine Commits in den origin/master pushen. Oder du fasst zuerst all deine Commits zu einem einzigen zusammen. Oder du machst erstmal ein [c]git fetch && git rebase origin/master[/c], fasst danach deine Commits zusammen ([c]git rebase -i HEAD~6[/c]) und aenderst noch den Text fuer den Commit ([c]git commit --amend[/c]) um schliesslich alles in einem Commit zum Shared Repo zu pushen.

Das klingt jetzt sicherlich verwirrend und total umstaendlich, aber wenn man dieses Vorgehen einmal verinnerlicht hat, kann man ohne Git nicht mehr arbeiten.

Zum eGit kann ich nicht viel sagen, ich arbeite mit IntelliJ - aber auch dort kann die Git Integration bei weitem nicht das leisten, was auf der Console moeglich ist.

Git hat uebrigens auch ein CVS Server eingebaut (git-cvsserver(1)). Damit kannst du mit Git arbeiten, waehrend deine Kollegen ganz normal mit CVS weiter machen.

 

[TheDarkRose]

Bitte nicht mit rebase arbeiten, die bringt die ganze historie durcheinander. besser lässt es sich mit merge arbeiten.

@TO
Ich würde nicht jeden Commit ins zentrale Repo sofort commiten. Das ist insofern das praktische an Git. du kannst einfach mehrere kleine Änderung in dein lokales Repo commiten, hast sofort deine History falls du was rückgängig machen willst, etc. Wenn du dann alles getestet hast, dass es funktioniert, kannst du es ins zentrale Repo pushen (in eGit heißt das schön Push to Mainstream) und es braucht sich kein andere Entwickler Gedanken machen, das plötzlich nichts mehr geht.
Ihr könnt auch am zentralen Repo ein Hookscript einrichten, das nach einen Commit eine Email an alle verschickt, das eben ein Commit ausgeführt wurde, am besten noch mit dem Changelog der letzten Commits.

 

[schalentier]

Bitte nicht mit rebase arbeiten, die bringt die ganze historie durcheinander. besser lässt es sich mit merge arbeiten.

Naja, man sollte keine "fremden" Commits rebasen, aber meine lokalen schon. Sonst sieht ja jeder meine ganzen (lokalen) Commits mit Commit-Messages wie: "fixed", "geht doch nicht", "behoben", "ALLES MIST" usw. Die pack ich dann vor dem push doch lieber zu einem richtigen Kommentar zusammen ;-)

 

[Firephoenix]

Hi,
ich hab dir deswegen auch mal ne PN geschickt, ansonsten nochmal die Frage an den Rest:
Wie genau gehe ich bei eGit vor wenn ich eigene Commits zusammenfassen will.

Z.b. erzeuge ich einen branch "Work" abgehend vom master, mache dort meine Commits.
Normalerweise würde ich jetzt von Work aus wieder zu master mergen und dann work löschen, die rebase-alternative klingt aber besser.
Was genau muss ich dann machen um die Commits von work zusammenzufassen und wieder in master reinzukriegen?
Gruß

 

[TheDarkRose]

Rebase erzeugt automatisch einen neuen Commit, und fasst die alten in diesen neuen zusammen. Ein Merge hingegen, kopiert alle Commits aus den zu mergenden Branch, außer man setzt die Option --no-ff oder es gibt Konflikte. Dann wird auch ein neuer Commit erzeugt, aber die alte History leibt erhalten. Man kann dann schön in der Git Commit History sehen, welche Commits in einen eigenen Branch waren.

A successful Git branching model » nvie.com

 

[Firephoenix]

Hi,
ich kriegs immer noch nicht hin einen feature-branch als einen Commit in den Master zu bekommen, bei mir fliegen immer sämtliche Commits des feature-branches mit in den Master.
Das hier ist meine Ausgangssituation, master ist das hauptprogramm in das das feature integriert werden soll.
feature ist der branch in dem besagtes feature entwickelt wurde.

Wenn ich jetzt feature3 wähle und das in master rebase bekomme ich das hier:

Mache ich in der situatin wenn ich feature3 ausgewählt habe statdessen einen Rechtsklick auf master und dann rebase on top of bekomme ich:

Was ich aber eigentlich haben will ist, dass master einen commit vorrückt, der alle commits in feature zusammenfasst, wie mache ich das?
Gruß

 

[schalentier]

Hast du TortoiseGit? Dann musst du alle Commits im Featurebranch markieren und Combine commit... oder so aehnlich aufrufen. Da wird dann aus den markierten genau ein neuer Commit, den du dann rebasen kannst.

Auf der Console geht das mit [c]git rebase -i[/c], dann die Commits auswaehlen, die du zusammenfassen willst (squash) und [c]git commit --amend[/c] um den Commitkommentar zu veraendern.

 

[Lexi]

Oder du machst erstmal ein

git fetch && git rebase origin/master

[...]

Wieso kein

git pull origin/master

?

 

[schalentier]

Weil dann deine ganzen (moeglicherweise viele) lokalen Commits mit denen aus dem master vermischt sind. Mit rebase kommen erst alle vom master, dann alle deine lokalen. Find ich praktischer.

 

[TheDarkRose]

Weil dann deine ganzen (moeglicherweise viele) lokalen Commits mit denen aus dem master vermischt sind. Mit rebase kommen erst alle vom master, dann alle deine lokalen. Find ich praktischer.

Find ich persönlich unschön, da dann die Timeline der Commits nicht mehr passt.

 

[schalentier]

Haengt halt stark vom verwendeten Workflow ab, ob rebase oder pull. Wenn ich jedes Feature/Bug in einem eignen lokalen Branch entwickle, pack ich vorm push in den origin/master eh alle meine Commits (fuer dieses Ticket) in einem Commit zusammen. Dann ist es imho einfacher, wenn all meine Commits ganz oben in der History stehen.

Aber man muss mit git nich so arbeiten, dann ist pull evtl. besser (hab keine wirklichen Erfahrungen damit - ich mach eigentlich immer [c]git fetch && git rebase origin/master[/c]).