(fertsch)Git

[joggel]

Hallo Leutz,

ich habe diesmal eine ganz triviale Frage: Ich möchte meine Projkete mit Git verwalten.
Also ich habe schon Projekte, und diese möchte ich eben verwalten.

Kann mir jemand, für Dummies, erklären wie man dabei vorgeht?
Ich möchte die Projekte auf einem Netzlaufwerk, oder Server, ablegen, dort die Änderungen einchecken, und von dort eben auch auschecken.
Ich blick das irgendwie nicht so wie das geht :(

[xq]

Git lernen: https://try.github.io/levels/1/challenges/1

[joggel]

Das habe ich schon mal ausprobiert.
Aber okay...ich werde es nochmal machen. Diesmal nehme ich mir zeit, vlt checke ich es ja

[Tiles]

Ich manage meinen Github Account immer noch hauptsächlich über TortoiseGit. Mir sagt eine grafische Oberfläche einfach mehr zu als die Konsole.

Ich möchte die Projekte auf einem Netzlaufwerk, oder Server, ablegen, dort die Änderungen einchecken, und von dort eben auch auschecken.

Ich habe damals probiert Git auf meinem Server zum Laufen zu kriegen. Als dann auch noch ein befreundeter Informatiker da dran gescheitert ist bin ich doch auf Github umgezogen :D

[joggel]

Habe es gerade hinbekommen. Danke. Ich verwende jetzt auch TortoiseGit!!! :)

[Specialist]

Ich kann hier nur GOGS (GO-GitService) empfehlen.
Das läuft auch wunderbar auf einem RaspberryPi.
Die Installation ist selbst für Nicht-Linux-Kenner recht einfach.

[CrystalCoder]

Hi,

ich weiß, du hast schon was gefunden, aber ich finde es wäre ganz gut mal ein paar Hintergründe zu git zu benennen, als nur zu sagen "schau dir paar Tutorials an und benutze Software XYZ".

Also here we go:
Die wahrscheinlich beste (aber auch nicht ganz so einfache) Variante mit git zu arbeiten wäre die Git-Bash for Windows (wenn man denn unter Windows arbeitet). Damit kann man es genau so bedienen, wie man es bei Mac oder Linux tun würde. Eine Grafische Oberfläche ist hilfreich, wenn man Dateien einchecken will und eine Side-by-Side view haben möchte. Das Verwalten von branches (außer commit und push) würde ich auf jeden Fall in der Konsole machen.
Als Backend habe ich mir erst kürzlich eine Bitbucket Lizenz zum selbst hosten gekauft (läuft auf einem Tomcat Server, die installation ist einfach und kostet nur einmalig 10$), allerdings braucht man einen (v)Server mit root access dafür (ich hoste das bei CloudAtCost, weil es billig ist, aber Performance ist da eher unterirdisch - für meinen kram reicht's aber).

Das Grund-Prinzip von git ist einfach:
Es gibt zwei Orte, wo die Projekte abgelegt werden. Ein remote repository und ein lokaler clone. Wenn man also das Projekt auscheckt, dann klonst du quasi das Projekt (bzw. einen "branch"). Die Änderungen machst du lokal, commitest du lokal und pusht diese dann zum Server.

Etwas mehr im Detail:
Jetzt ist es so, dass das remote repository wie ein Baum aufgebaut ist: der Root wird normalerweise "master" genannt und is an sich nur ein normaler branch (ähnlich wie ein Window unter Windows). Das erstmalige auschecken holt jetzt nur den "master" vom Server ab.
Wenn man alleine arbeitet, dann wird man oft einfach mit dem "master"-branch arbeiten aber dazu würde ich nicht raten. I.d.R. geht man folgendermaßen vor: Man macht einen "branch" und lässt ihn von einem anderen branch abzweigen und "pusht" diesen erstmal zum Server. Die branches kann man benennen, wie z.B. "feature1". Die lokale Arbeitskopie ist immer ein bestimmter branch, wie hier z.B. "feature1". Jetzt kann man alle code-Änderungen da drin vornehmen und der "master" bleibt davon erstmal unberührt. In regelmäßigen Abständen (bei Meilensteinen z.B. kann man seine Änderungen "commit"en. Commit bedeutet hier nur, dass man die Code-Änderungen nur in den lokalen branch "feature1" eincheckt. Hat man einen funktionierenden Stand, oder einen Stand, den man gerne auf dem Server hätte, dann "push"t man den "feature1" branch zum Server.
Damit hat man jetzt zwei Projektzustände auf dem Server: Das Projekt wie es vorher war und alle Änderungen, die man am Code vorgenommen hat in "feature1".
Jetzt kann man, wenn man das Feature in sein Projekt integrieren will, lokal den "master" auschecken ("git checkout master" in der Konsole). Danach "merge"d man seinen neuen Code aus "feature1" in den master mit "git merge feature1". Nun ist das Projekt lokal auf dem neuesten Stand, aber noch nicht auf dem Server. Man kann den "master" auf dem Server nun auch aktualisieren, mit "git push".

Der Vorteil dieser Methode, ist dass der Code auf dem Server sicher ist, selbst wenn man versehentlich etwas falsch macht.

Mit branches zu arbeiten empfiehlt sich aus mindestens drei guten Gründen:
1. Man hat immer einen "master" der bereit ist, um eine neue Version daraus zu "taggen".
2. Alle Änderungen sind Kategorisiert nach Thema; Systeme wie JIRA erlauben es branches und sogenannte Stories (z.B. für Planung und Umsetzung neuer Features) zu verknüpfen - branches werden oft nach Ticketnummern benannt.
3. Wenn viele Personen an den gleichen Projekten arbeiten, dann kann jeder von einem funktionierenden Stand anfangen (dem master)

Das Abzweigen von branches ist dabei nicht limitiert. Man könnte z.B. folgende Hierarchie bauen:
master: Enthält eine Mathebibliothek
|-> Vector-addition-feature: Ein branch bei dem Vektor-Unterstützung eingebaut werden soll
|-> Vector3d: Hier wird nur Unterstützung für 3D Vektoren eingebaut
|-> Vector2d: So wie oben, aber für 2D Vektoren
|-> Performance-Improvements: In diesem Branch baut jemand aus einer anderen Abteilung performance-improvements ein

Nun kurz zum Thema Konsole vs. GUI: Sicher ist es einfach mit einer GUI zu arbeiten, allerdings würde ich immer dazu raten, so viel wie es geht mit der Konsole zu machen, aus dem Grund, weil man mit einer GUI so seine Probleme haben kann, wenn mal etwas falsch gemacht wird (z.B. lokal in einen falschen branch committed). Die Konsole ist letztendlich das, wodrauf die GUI's basieren und kann deswegen als "single source of truth" angesehen werden, wenn man wissen will, wie es um das Repository steht. Wer die Konsolenbefehle verinnerlicht hat, dem wird git besonders einfach fallen, auch wenn es anfangs etwas schwierig ist (und ja es wird einfacher auch für Konsolen-Muffel wie ich es selbst mal war :D ).

Das wichtigste is, dass man immer an das Grund-Prinzip der "zwei Repositories" denkt wenn man mal Schwierigkeiten hat, etwas zu verstehen.
Ach ja: Nicht alle branches, mit denen man arbeitet muss man auch zwingend auf dem Server hinterlegen. Das ist nur praktisch wenn man später im Projektfortschritt sehen will, was man so gemacht hat. Manche Projektteams löschen remote branches, nachdem sie diese in den "master" gemerged haben.

Ich hoffe das war hilfreich. Wenn ich irgendwo Blödsinn geschrieben hab, oder was unklar ist, korrigiert mich bitte/ergänzt was fehlt.

Viel Spaß noch mit git.

[Tiles]

Jopp, spätestens sobald da mal zwei Leute oder mehr am werkeln sind, oder ein haariges Problem angehst von dem du die Auswirkungen noch nicht kennst, geht kein Weg an Branches vorbei. Allerdings kann man mit zu vielen Branches auch mal schnell die Übersicht verlieren. Also nicht übertreiben. Und immer gut und sinnvoll beschriften - Hat jemand ne Zeitmaschine übrig? :lol:

Nun kurz zum Thema Konsole vs. GUI: Sicher ist es einfach mit einer GUI zu arbeiten, allerdings würde ich immer dazu raten, so viel wie es geht mit der Konsole zu machen, aus dem Grund, weil man mit einer GUI so seine Probleme haben kann, wenn mal etwas falsch gemacht wird

Ich kann schon verstehen dass viele die Konsole bevorzugen. Aber die von dir hier angesprochenen Probleme hast du genau so auch mit der Konsole. Plus Tippfehler. Plus dem Gesuche welche Befehle du denn gerade brauchst. Und dem anschliessenden Gefluche weil es doch der falsche war. Ein Button hat wenigstens noch einen Tooltip. Und deswegen tendiere ich zur grafischen Lösung wo es irgend geht. Geht imho schneller und einfacher :)

Es gibt ja auch nicht nur TortoiseGit. Ich bin zum Beispiel vor Kurzem über GitKraken gestolpert. Für den Open Source Einsatz kostenlos: https://www.gitkraken.com/features

[CrystalCoder]

Ich kann schon verstehen dass viele die Konsole bevorzugen. Aber die von dir hier angesprochenen Probleme hast du genau so auch mit der Konsole. Plus Tippfehler. Plus dem Gesuche welche Befehle du denn gerade brauchst. Und dem anschliessenden Gefluche weil es doch der falsche war. Ein Button hat wenigstens noch einen Tooltip. Und deswegen tendiere ich zur grafischen Lösung wo es irgend geht. Geht imho schneller und einfacher :)

Man gewöhnt sich schnell an die Konsole und wie ich vorher schon meinte, eine Kombination aus beidem GUI+Konsole ist schon nützlich. Was Tippfehler angeht: Da gibt es auch noch auto-completion.
Klar kann man auch auf der Konsole Fehler machen, aber ich hab noch keine gute GUI gefunden, die wirklich so effektiv ist, solche Sachen wieder zu beheben wie die Konsole selbst, weil dort eben alles geht.

[joggel]

Danke!! Ich werds mir mal in Ruhe durchlesen.

Gruß