[How To] Versionskontrolle für den Source

  • Hi,


    ich habe Langweile deswegen schreibe ich einfach mal diesen Guide, da viele nicht die Vorteile der Versionskontrolle kennen.
    Außerdem helfe ich gerne Leuten, falls ich gerade Lust drauf habe (obwohl viele wahrscheinlich einen anderen Eindruck haben).



    Wieso Versionskontrolle?


    Versionskontrolle wird euer Leben leichter machen.
    Stellt euch vor, ihr wollt mit mehreren am Source arbeiten. Aber wie tauscht ihr die Änderungen aus? Dateien hin und her schicken?
    Ihr bearbeitet es alle auf einem Server, wobei es Probleme geben kann, wenn mehrere gleichzeitig die gleiche Datei bearbeitet?
    Jemand snitcht und löscht den ganzen Source und ihr habt kein aktuelles Backup?
    Ihr wollt einen Überblick darüber, was geändert wurde?


    Ohne Versionskontrolle ist es fast unmöglich all diese Probleme zuverlässig zu lösen.


    Versionskontrollsysteme (bzw. Git) hat keinen zentralen Dateispeicher, wodurch es sich von anderen Versionskontrollsystemen (z.B. SVN) unterscheidet.
    Die Dateien werden bei jedem einzelnen Client gespeichert, im sogenannten "Repository" werden nur Änderungen gespeichert.
    Das macht es auch einfach Änderungen rückgängig zu machen (z.B. wenn eine Fotze alles gelöscht hat).


    Durch Git könnt ihr auch (auf Basis der normalen Dateien) in verschiedenen "Branches" arbeiten, um z.B. Features, Fixes oder sonst was einzubauen.
    Dieses kleine Modell sollte es für jeden einigermaßen verdeutlichen:




    Was ihr braucht


    • Git für Windows (Link: Bitte melden Sie sich an, um diesen Link zu sehen.)
    • Einen Source
    • Einen Github/bitbucket Repository


    Optional könnt ihr auch Explorererweiterungen, wie z.B. TortoiseGit, installieren.
    Dadurch kann man über das Kontextmenü die lokalen Repositories verwalten, ist ganz cool.


    Wir hatten damals bei WoM2 immer bitbucket Repositories, glaube hat da niemanden gejuckt.
    Deswegen würde ich bitbucket empfehlen.




    Zum Guide


    Nachdem ihr alles besorgt habt, geht es mit dem clonen los.
    Dazu könnt ihr euch einen neuen Ordner erstellen. Geht in den Ordner (oder irgendeinen anderen), macht einen Rechtsklick und wählt "Git Bash here" aus.
    Das Git Bash ist ein kleiner Unix Terminal Emulator, dort könnt ihr also normale Unix Befehle benutzen.


    Bevor ihr etwas commiten ("Speichern" von Änderungen) könnt, müsst ihr jedoch zuerst einen Namen und eine Email für den Git log festlegen.
    Dies könnt ihr mit folgendem Code machen:


    Code
    1. git config --global user.email "email"
    2. git config --global user.name "name"


    Zum "clonen" (lokales Speichern eines Repositorys) benötigt ihr einen HTTPS oder SSH Link zu eurem Repository.
    Github/bitbucket stellen euch diese bereit. Welchen ihr davon nutzt ist eigentlich ziemlich egal.
    Git Befehle laufen immer über den Interpreter "git". Zum clonen wäre es also der Befehl "git clone <link>".
    Beispiel: "git clone Bitte melden Sie sich an, um diesen Link zu sehen.".


    Nachdem ihr das Repository geclont habt, werdet ihr einen neuen Ordner mit dem Namen des Repositorys sehen.
    In diesem Ordner ist der Inhalt des Remote-Repositorys und die dotfiles (interne Git Dateien im ".git" Ordner)


    Nun habt ihr ein neues lokales Repository erstellt und könnt euren Source reinkopieren.
    Ihr könntet auch ein neues Repository in dem Source Ordner erstellen.
    Dies würde jedoch mehr Erklärungen erfordern (remote origin hinzufügen, usw) und da habe ich gerade keinen Bock drauf.
    Wer sich dafür interessiert kann es ja immer noch nachlesen.


    Wenn ihr in einer Datei etwas geändert habt, eine Datei hinzugefügt habt, eine Datei gelöscht habt, oder was auch immer, könnt ihr den Befehl "git status" benutzen um zu sehen, welche Datei verändert wurde.
    Wenn Dateien hinzugefügt wurden, müsst ihr diese erst "adden" um sie commiten zu können.
    Dies geschieht mit dem "git add <datei>" Befehl.
    Wenn es mehrere Dateien sind, könnt ihr alternativ auch "git add ." nutzen. Durch den "." als Parameter werden alle neuen Datei automatisch geadded.
    Das könnt ihr natürlich auch nutzen, wenn es nur eine neue Datei gibt.


    Wenn ihr Änderungen vorgenommen und ggf. die Dateien geadded habt, müsst ihr den "git commit" Befehl nutzen, um die Änderungen im lokalen Repository zu übernehmen.
    Der commit Befehl braucht eine commit message für den Git log. Diese Nachricht könnt ihr über den -m Parameter übergeben.
    Beispiel: git commit -m "test"


    Um die Änderungen nun im Remote-Repository zu übernehmen müsst ihr den Befehl "git push" Befehl benutzen.
    Dieser Befehl benötigt keinen standardmäßig keine Parameter, kann also einfach so genutzt werden.
    Jedoch ist es wahrscheinlich, dass Git euch auffordert, euch wenigstens ein mal mit euren Github/bitbucket Anmeldedaten einzuloggen.


    Nachdem ihr den push Befehl genutzt habt, können andere Leute, die Zugriff auf das Remote-Repository haben, mit dem "git pull" Befehl auf ihrem PC übernehmen.
    Der pull Befehl benötigt ebenfalls standardmäßig keine Parameter und kann einfach so genutzt werden.


    Für die, die sich dazu entschlossen haben, TortoiseGit zu nutzen: ihr müsst diese Befehle nicht in der Git Bash nutzen.
    Ihr habt alles als Menüpunkte im Windows-Kontextmenü. Dazu einfach einen Rechtsklick auf die Ordner/Dateien machen.



    Schlusswort

    Keine Ahnung ob jemand von euch es nutzen wird oder sich dafür interessiert, wollte es aber wenigstens probieren, etwas Professionalität durchzusetzen.
    Wenn ihr euch wirklich dafür interessiert, empfehle ich euch wenigstens den Starterguide von Github durchzugehen (Bitte melden Sie sich an, um diesen Link zu sehen.)
    Dort werden euch grundlegende Befehle etc beigebracht.
    Zu eurer Info: dieser Guide war nicht dazu gedacht, in-depth Git beizubringen. Viel mehr lag der Sinn darin, die Möglichkeiten/Vorteile von Git und einen kurzen Weg um Git für den Source nutzen zu können zu beschreiben.



    MfG Remix

  • Dieses Thema enthält 4 weitere Beiträge, die nur für registrierte Benutzer sichtbar sind, bitte registrieren Sie sich oder melden Sie sich an um diese lesen zu können.