WoltLab Community Forum

Quoted from "philipp-schoene"

Quoted from "Netzwerg"

Empfehlenswert ist es, sich solche Dinge gar nicht erst anzugewöhnen.

Wieso machen die das in GIT das nicht dann anders?

Kopf => Tisch
Kopf => Tisch
Kopf => Tisch


Sorry, der musste jetzt sein. Ähm ja, ich glaub, du brauchst nochn paar Erklärungen...

Das ist kein GIT Problem.... sondern hat schlichtweg etwas mit Deployment zu tun.

Ok, schauen wir uns mal an, warum das ganze zu einem Problem führt bei den WCF-Paketen.

Das WCF hat folgende Ordnerstruktur (nur für das Problem relevantes):

Ok, ein standardmäßiges WCF-Paket hat folgende Struktur:

Das alles wird zur package.tar gepackt.

Ok, beim Installieren entpackt das WCF das Paket wie folgt:


Ich denke, nun dämmert dir auch langsam, wieso man die Repos für WCF Pakete kaum im htdocs - Ordner erstellen kann. Wie gesagt, das ist nur *ein* Beispiel dafür, wieso man damit Probleme bekommen kann, Fallstricke lauern auch an anderen Enden. Und eben deshalb ist das eher nicht zu empfehlen.

So lange du nur eigene Webseiten schreibst und Kontrolle darüber hast, was da wie passiert kannst du natürlich deine Repos im htdocs Ordner erstellen. Nur wie gesagt, ich würds nicht tun.

Omfg, nimm das doch nicht gleich persönlich.

Ich schlage mir hier nun schon Stunden um die Ohren, um dir Dinge zu erklären, die du (noch) nicht weißt, und weil ich den Eindruck habe, dass du tatsächlich etwas lernen willst. Nun ja, dazu gehört manchmal auch, dass man auf dem Holzweg ist, und du bist verdammt nochmal gerade ziemlich auf dem Holzweg.

Quoted

Vielleicht mal dein Gehirn einschalten, wenn du liest: Wenn einige Projekte und Anwendungen Probleme damit haben, wieso wird GIT dann nicht so verbessert, dass man das Repo-Verzeichnis und die .git im Dateisystem trennen kann?

Das würde das oben geschilderte nicht ändern. Selbst wenn das Arbeitsverzeichnis wo anders wäre, schau dir mal die Ordnerstrukturen an, die ich da gezeigt habe. Das Problem hast du übrigens auch nicht nur mit GIT, sondern auch mit Mercurial, SVN und schlagmichtot was für Systeme es noch alle gibt.
Das liegt schlichtweg daran, wie man bestimmte Arten von Projekten verbreitet (Deployment). manche Projekten werden verbreitet, indem man sie 1:1 so verwenden kann. Ja, solche kannst du im htdocs Ordner ablegen (schrieb ich ja bereits). Es gibt aber auch andere Arten von Software, bei denen da noch Zwischenschritte nötig sind, wie beim WCf z.B. das installieren über die passenden PIPs aus einem Paket. Oder wenn du ne Webapplikation für Java entwickelst das compilen und packen als JAR. Wenn du ein C(++) Programm schreibst ebenfalls das compilen. Diese Dinge liegen alle außerhalb des Einflussbereiches und außerhalb des Verantwortungsbereiches eines VCS. Dafür wiederum gibt es Tools wie make, Ant, Maven oder wie sie alle heißen. Fürs WCF z.B. stellst codingcorner.cc eine CI mit Jenkins bereit. das ist nur eine Frage der Auswahl der passenden Werkzeuge für die passenden Aufgaben. Ich selber verwende für meine WCF Pakete z.B. make.


Ich geb dir nur nen gut gemeinten Rat:
Wenn du Leuten, die sich stundenlang zeit nehmen, um dir Dinge zu erklären, mit so Sprüchen wie "Gehirn einschalten / abschalten" kommst, verlieren die ziemlich schnell die Lust daran, dir etwas zu erklären. Ich weiß jetzt nicht was an meiner Aussage "Kopf => Tisch" schlimm sein soll (und werde mich dafür auch nicht entschuldigen), du kannst die Aussage so auffassen, dass jemand in einem Gespräch mit dir die Hände über dem Kopf zusammenschlägt, seufzt und sich anschließend eine neue Erklärung überlegt, in einer der größten WCF Communities (wbbaddons.com) gibts dafür sogar nen passenden Smilie (mal dreist als Hotlink: ). Ich weiß ja nicht wo das herkommt, dass du dich gleich so angegriffen fühlst.

Dann bleibt das Problem weiterhin bestehen. Die Dateien in .git kannst du nicht verwenden. Die werden von Git entsprechend verwaltet. Die für dich wichtigen Dateien fürs Deployment liegen eine Ebene höher. Und dort musst du bei einem WCF-Paket eben eine WCF-Paketstruktur drinnen haben und nicht die fertige Struktur nach der Installation (kann man zwar auch machen, allerdings brauch man dann zum Packen wieder kompliziertere Buildskripte). Wenn du nun das Paket testen willst, dann installierst du es einmal und danach kannst du, wenn sich nur Dateien verändern, die Änderungen immer ins Testverzeichnis auf dem Webserver kopieren.

Quoted from "philipp-schoene"

Ich wollte nie mit den Dateien in .git arbeiten. Ich meine das Verzeichnis, welches Git parallel dazu anlegt.

Das meinen wir auch

Quoted

Kann man damit auch so offizielle Versionen wie beim WBB 3.1.7 oder so definieren?

Solche Versionen haben mit dem VCS erstmal wenig zu tun. Versionsnummern sind Schall und Rauch. Du gehst einfach hin, sagst "das ist mein Stand X, und das Release ich jetzt als Version X.Y.Z". GIT unterstützt das Taggen von Objecten, du kannst also deinen aktuellen Stand als diese Version taggen, damit jederzeit nachvollziehbar ist, was du da gemacht hast.

Quoted

Lässt sich eine Chancelog generieren?

Theoretisch ja, in der Praxis eignen sich die Commit-Messafes meistens eher weniger für Changelogs, da diese meist recht technisch und sehr detalliert sind. Stell dir mal vor, du korrigierst nur ein paar fehler, wie z.B. fehlende Tabs, Whitespaces, Absätze, korrigierst ein paar Rechtschreibfehler in Kommentaren. Dann sieht deine Commit-Nachricht in etwa so aus "Fixed typos, tabs & whitespaces". Das passt in ein Changelog schlecht rein. Ich sage nicht, dass es nicht geht, es ist meisten nur unpraktisch. Du könntest dir z.B. mal das hier anschauen: https://github.com/dploeger/milestone2changelog

Quoted

Was noch nicht richtig gelöst ist, ist das uploaden der Dateien. Dazu benutze ich derzeit ein Tool, was ich sonst zum Sichern einsetze. Dieses synchronisiert mein lokales Verzeichnis mit dem auf dem Webserver und spart die Eklipse-Dateien aus.

Geht es dabei um ein simples synchronisieren der Dateien (z.B. mit dem Webserver, wo die Software läuft) oder ums pushen in ein Remote-Repository?

Quoted from "philipp-schoene"

Ich wollte nie mit den Dateien in .git arbeiten. Ich meine das Verzeichnis, welches Git parallel dazu anlegt.

Git selber legt außer dem .git-Verzeichnis kein paralleles Verzeichnis an. Du erstellst ein Verzeichnis, begibst dich dort hinein und gibst dann auf der Konsole git init ein. In dem aktuellen Verzeichnis wird dann .git/ angelegt.

Quoted from "philipp-schoene"

Kann man damit auch so offizielle Versionen wie beim WBB 3.1.7 oder so definieren?

Die Versionierung findet hauptsächlich in der package.xml des Paketes statt. Ansonsten hast du commits. Welcher commit-Stand dann zur Version X.X.X wird, entscheidet sich dann meist spontan.

Quoted from "philipp-schoene"

Lässt sich eine Chancelog generieren?

Automatisch ist das, wie bereits gesagt, nicht wirklich sinnvoll.

Quoted from "philipp-schoene"

Ich müsste doch auch auf einen anderen Rechner auf das Repository zugreifen können, oder?

Auf das auf deinem Rechner? Eher nicht, denn dafür muss dein Rechner auch gleichzeitig im Inet und vom Inet aus erreichbar sein und das Repository zugänglich sein. Aber du kannst ein Remote-Repository nutzen.

Quoted from "philipp-schoene"

Wenn du Pakete erstellst. wie erstellst du dir die changelog und Versionsnummern?

Naja du hast eine Anfangsversion (bei Neuentwicklung 1.0.0, ansonsten halt das letzte Release) und machst dann die Änderungen für das nächste Release. Irgendwann (weil du alle Vorschläge/Bugs im Bugtracker umgesetzt/behoben hast oder weil du denkst das ist reif für ein Release) entscheidest du dich dann dafür den jetzigen Stand zu releasen. Den packe ich dann in einen release-Branch und teste noch einmal ausführlich, ob sich nicht noch auf den letzten Metern neue Bugs eingeschlichen haben. Wenn ich zufrieden bin, dann gehe ich in die package.xml und gebe dort die Versionsnummer an und gegebenenfalls die Updateanweisungen. Das commite ich nun und merge dann diesen Branch in den master-Branch und tagge das dann mit der Version. Zusätzlich merge ich den Releasebranch zurück in den dev-Branch.

Die Changelog ergibt sich dann für mich aus den Bugs, die ich behoben habe (prominente werden extra genannt, ansonsten einfach "fixed plenty of bugs") und aus den Features, die ich verbessert bzw. eingebaut habe. Diese werden dann einzeln genannt.

Quoted from "philipp-schoene"

Wie kann ich auf das Repository von einem weiteren Programm zurückgreifen?

Dazu eignet sich ein Remote-Repository (z.B. auf Github). Auf dieses kannst du dann von mehreren Rechnern aus zugreifen.

Quoted from "philipp-schoene"

Also macht ihr das immer noch per Hand in eine Textdatei?

Manchmal, aber eher mit einem Issuetracker / Bugtracker. Teils habe ich auch einefach eine TODO.txt Datei, wo ich reinschreibe, was noch erledigt werden muss. Wenn ich dann dort Dinge abhake kommen sie in die Changelog.txt.

Quoted

EGit, kann doch nur mit dem lokalen Repository arbeiten. Kann man das irgendwie mit einem Remote-Repository abgleichen? Muss ich da Github benutzen. Ich entwickle meist allein, da macht das dann keinen Sinn. Kann man sich selbst so einen Server erstellen? Wenn ja, welche Voraussetzungen braucht man?

Auch wenn man allein entwickelt macht GitHub Sinn. Einen eigenen Server dafür aufzusetzen ist umständlich und erfordert wiederum auch Wartung etc.pp. Ein Tutorial zu einem eigenen GIT-Server findet man u.A. hier:http://tumblr.intranation.com/post/76629…it-server-linux

Quoted

Was ist ein Branch?

Eine Branch ist ein Entwicklungszweig.

Nehmen wir mal an, du willst ein neues Feature zu deinem Programm hinzufügen. Dann bietet es sich an, eine neue Branch anzulegen, die auf dem derzeitigen - stabilen - Stand basiert. In dieser Branch entwickelst du das neue Feature so lange, bis es stabil ist. Anschließend mergest du die Entwicklungs-Branch in die 'master'-Branch rein.
Das hat den Vorteil, dass du zunächst das neue Feature entwickeln kannst, bis es stabil läuft, ohne die 'master'-Branch zu belasten (diese bleibt stabil).

Quoted

Im Beitrag 70 habe ich ein Bild gepostet, welches die Pfade zeigt, wie die von EGit gesetzt werden. Unter Target Location steht D:/Projektname/Projektname. das kann man nicht ändern.

Ich verstehe nicht wirklich, was du nun damit sagen willst? Du hast trotzdem hinterher in dem Repo das .git/ Verzeichnis. Wenn du das repo mit EGIt anlegst ist es nur so, dass Eclipse als Arbeitsverzeichnis des Projektes einen Unterordner des Arbeitsverzeichnis des Repos nimmt, und nicht das Arbeitsverzeichnis des Repos selbst. Das kann man aber - wenn man möchte - umgehe, indem man per git init das Repo selber anlegt und dann mittels EGIT mit dem Projekt verbindet und den Haken setzt bei "Use repository in parent folder of project".

Quoted from "philipp-schoene"

Mir gefällt an Github nicht, dass das alles offen ist. Ist es nicht möglich z. B. per FTP so ein Repository zentral abzulegen? (Dabei wäre mit das zentrale wichtiger, als die Performance)

FTP dafür zu benutzen ist theorteisch möglich, killt aber den Sinn von GIT. (da du einfach mit dem Brecheisen den .git/-Ordner überschreiben würdest und somit potentiell Daten aus dem Repo verlierst).

Für welchen Zweck benötigst du denn ein Remote-Repository?

Quoted

Mir gefällt an Github nicht, dass das alles offen ist.

Es gibt recht günstige Pläne für private Repos, als Student bekommt man den kleinsten Plan sogar umsonst

Quoted

Also kann ich von Projekt ein Feature entwickeln, aber auch kleine Sicherheitsupdates fahren, oder? In der Praxis, habe ich das an meinen Projekt nicht hinbekommen.

Jop.
Für den Anfang kommt man aber auch ganz gut ohne Branches aus. Man muss ja nicht gleich versuchen alle Features von GIT auf einmal vollständig zu verstehen. Manchmal ist es etwas einfacher, kleinere Schritte zu gehen. Bei GIT-Submodulen z.B. bekomme auch ich noch mitunter Kopfschmerzen

Quoted from "philipp-schoene"

Das Remote-Repository wollte ich zum Bearbeiten des Projekts auf meinen Rechner bzw. Laptop nutzen.

Du kannst das Repo auch zwischen deinem Rechner und deinem Laptop synchronisieren, da ist nicht umbedingt der Umweg über ein Remote-Repository nötig.


Infos zum Studentenangebot von GitHub: https://github.com/edu

Dateien ignorieren kann man über entsprechende Einträge in einer .gitignore - Datei.

Zum Index: http://www.gitguys.com/topics/whats-the-…-the-git-index/

Pro Zeile eine Datei / Verzeichnis, * ist eine Wildcard.

In wie fern hast du nen Konflikt? Wie hast den denn erzeugt?

Nö, so weit ich das sehe ist das richtig.

Die beiden branches kannst du mergen, dann wird dir ggf. nen merge conflict angezeigt, den du zunächst beheben musst, danach kannst werden dann beide Branches zusammengeführt. Dann kannst du die nicht mehr benötigte Branch löschen.