Einstieg in GIT

[MisterX]

Hi Ho,

ich beschäftigt mich gerade mit GIT. Die Grundzüge mit init, add und commit sind mir jetzt soweit klar.
Jetzt geht es eine Stufe weiter mit mehreren Repositories.

Kann mir jemand die Befehle

git clone 
git remote add origin
git push
git pull

näher bringen?
Ich verstehe nicht ganz was bei einem "clone" genau passiert.
Dieses origin, master ist mir auch nicht ganz klar.

Die Tutorials im Netz haben mir nicht weitergeholfen. Da stehen oft kurz paar Befehle drin, aber was hier vorsichgeht wird leider nicht beschrieben.
Vielleicht kann mir jemand aus dieser Ecke weiterhelfen?

Gruß
HP

 

[schalentier]

[c]git clone[/c] kopiert im Grunde ein Repository auf deinen Rechner.
[c]git remote add origin[/c] verknuepft dein Repo mit einem anderen (remote), so dass push/pull's auf dieses remote Repo gehen sollen
[c]git push[/c] schiebt deine lokalen Commits zum remote repo (also jenes, von dem du geclont hast, oder mit dem du deins verknuepft hast)
[c]git pull[/c] holt Commits vom remote repo und merged sie in dein lokales (pull macht nacheinander: [c]git fetch[/c] und [c]git merge origin[/c]).

Gute Literaturquelle: Git - Book

 

[Tomate_Salat]

Verwende auch erst seit kurzm GIT, aber was ich glaube zu wissen:

git clone klont ein Repository. Wird z.B. verwendet um von einem Server ein Repository lokal zu holen. Da commiteste zwischenstände rein und sendest iwann alles wieder zum zentralen Repository (also das aufm Server). Mit push sendest du änderungen und mit pull ziehst du dir diese (und afair merged du diese gleich noch)

origin und master müssten Branches sein. Also zweige in denen du Arbeitest. Zweige werden benutzt, um etwas abseits deines Projektes zu entwickeln. Ist die Funktion soweit in Ordnung,dass diese ins Hauptprogramm übernommen werden kann, merged du diese in den master (master ist i.d.R. dein Hauptbranch).

git remote add origin - Keine Ahnung.

 

[schalentier]

origin und master müssten Branches sein.

Nope, nicht ganz. Nur master ist ein Branch (der Masterbranch, unter SVN sagt man trunk dazu). origin ist der Name eines Repos, origin wird per Default das Repo genannt, von dem du geclont hast.

 

[MisterX]

Danke für die Infos.

Wenn ich das richtig sehe kann ich verschiedene Repos nur zusammenführen wenn sie vorher geclont wurden, sprich von einem anderen Repository abstammen.
Ich glaub da muss ich vorher viel durchspielen oder kann man hier am Anfang viel falsch machen, dass sich später nicht mehr ändern lässt?
Gruß
HP

 

[schalentier]

Was meinst du mit "Zusammenfuehren"?

Man kann einen Clone eines bestehenden Repos erstellen. Aenderungen (=Commits), die du dann an diesem Clone machst, kannst du wieder zurueck pushen. Du kannst auch mehrere Clone erzeugen, in jedem irgendwelche Commits machen und diese dann quasi untereinander austauschen.

Was genau willst du machen?

 

[Tomate_Salat]

Ich würde einfach mal vorher ein wenig herumexperimentieren. Dadurch lernst du das System am besten kennen und ersparst dir den Gedanken: "MIST! hätte ich das früher gewusst, hätte das vieles vereinfacht" ;-).

Tu ich genauso. Hab hier lokal einige GIT-Repos die nur Müll enthalten. Aber zum testen/experimentieren reichts allemal

 

[MisterX]

Was meinst du mit "Zusammenfuehren"?

Was genau willst du machen?

Prinzipiell hätte ich mir das Zusammenführen so vorgestellt:
Person A erstellt ein Git-Repo und schreibt da ein paar Klassen. Person B macht das Gleiche und schreibt den anderen Teil der Klassen. Dann werden die beiden Repos irgendwann zusammengeführt.
Aber vermutlich wird das nicht gehen.
Da wird B am Anfang erst von A einen Clone erhalten müssen, den er dann zukünftig benutzen kann.

Das mit der Clonerei ist mir noch nicht ganz durchsichtig

 

[maki]

Hast du denn schon mal die Doku gelesen?

Mir scheint dass dir die Grundlagen fehlen, da können wir noch solange über Begrifflichkeiten/Befehle diskutieren

Oder hast du bis jetzt noch gar keine Erfahrung mit Source Code Versionierung (branchen/mergen/taggen)?
Dann würde ich zB. Subversion empfehlen, ist am Anfang einfacher als die dezentralen Versionierungssysteme wie zB. Git.

 

[MisterX]

Da hast Du vielleicht nicht ganz unrecht. Vielleicht sollte ich erst mit subversion anfangen.
Aber man hört nur noch git,git,git.
So mit einem eigenen Repo habe ich die Doku durch. Also Anlagen, Commit, Branch bilden. Branch zusammenführen. Aber die nächste Stufe ist nicht einfach.

 

[maki]

Bei Git wird sehr häufig gebrancht und gemergt, da kann es auch mehr bzw. macht es einfacher als Subversion.

D.h., wenn dir Subversion zu "klein"/umständlich wird, kannst du immer noch auf Git umsteigen, beides wird heute stark verwendet, wage mal zu behaupten dass Firmen eher Subversion als Git einsetzen, in der OSS Szene ist das natürlich anders.

Du musst natürlich nicht auf Subversion umsteigen, aber die Konzepte die hinter branchen, mergen, taggen usw. stehen musst du 100% verstanden haben, sonst wird das nix.

Wenn du nur alleine an deinem Repo arbeitest, fehlt dir leider die imho wichtigste Erfahrung, denn die interessanten/komplexen Aufgaben/Effekte kommen erst, wenn wirklich mehrere Leute am Code arbeiten.
An einem Git Repo ganz alleine zu arbeiten kann schon Sinn machen, aber im Team ist das eine ganz andere Sache

 

[kama]

Hallo,

Prinzipiell hätte ich mir das Zusammenführen so vorgestellt:
Person A erstellt ein Git-Repo und schreibt da ein paar Klassen. Person B macht das Gleiche und schreibt den anderen Teil der Klassen. Dann werden die beiden Repos irgendwann zusammengeführt.

Repositories kann man in Git nich zusammen führen.

Aber vermutlich wird das nicht gehen.
Da wird B am Anfang erst von A einen Clone erhalten müssen, den er dann zukünftig benutzen kann.

Richtig vermutet.
Man muss auch bei einem verteilten Versionskontroll-Tool mit einem Zentralen Punkt sprich dem ersten gemeinsamen Repository anfangen...sprich A mach zuerst eins oder B macht zuerst eines oder von einem Zentralen Punkt aus...Aber der Anfang ist genau EIN Repository...

Ich würde auch Empfehlen mit einem einfacheren Tool sprich Subversion anzufangen...

Das mit der Clonerei ist mir noch nicht ganz durchsichtig

Im Prinzip ist es einfach...einfach eine Kopie erstellen (mit voller Historie)...interessant wird das erst wenn man Änderungen pushed sprich zurück in ein anderes Repository gibt...

Gruß
Karl-Heinz Marbaise

 

[HoaX]

Falsch, man kann Repositories zusammenführen. Und es kann am Anfang auch mehrere geben, es _muss nicht_ eines der Ursprung aller anderen sein.

Wenn man Subversion gewohnt ist, dann ist der Umstieg auf Git auch nicht einfacher, da die ganze Denkweise anders ist. Solange man noch keine Erfahrung mit irgendeinem VCS hat, dann dürfte sich der Lernaufwand zwischen Git und SVN nicht zu sehr unterscheiden bis man die Basics kann, der Rest kommt dann schon von allein.

Statt klonen kannst du auch das ausführen:
git init
git remote add origin PfadZumFremdenRepository
git fetch origin
git reset --hard origin/master

Clone ist einfach eine einfachere, bequemere Schreibweise.

 

[maki]

HoaX,

man kann auch mit Subversion Repositories zusammenführen (export, filter, import), aber eben nicht vollautomatisch sondern mit Handarbeit, und wenn ich das richtig sehe, ist das in Git auch nicht viel weniger aufwändig.

 

[HoaX]

HoaX,

man kann auch mit Subversion Repositories zusammenführen (export, filter, import), aber eben nicht vollautomatisch sondern mit Handarbeit, und wenn ich das richtig sehe, ist das in Git auch nicht viel weniger aufwändig.

Doch eigentlich schon. Man muss nur:
1. Das fremde Repository per git remote add einbinden
2. git merge auf den zu importierenden Branch los lassen
3. ggf. konflikte lösen

Kein Unterschied zur sonstigen Arbeitsweise mit Git.