GIT
In dem Artikel Git-Repository erstellen erklärte ich die Verwendung von GIT in einem einfachen Umfeld.
Ich muss zugeben, dass ich die Versionierung vor allem für mich allein verwendete und mir war immer klar, dass ich die eigentliche Stärke der Versionsverwaltung nicht nutze. Schlicht und ergreifend, weil ich sie gar nicht brauchte.
Die Versionsverwaltung – vor GIT Subversion – verwendete ich vor allem dafür, um Fehler in Änderungen bei Projekten zurücknehmen zu können (Rollback).
Ob es mir gefällt oder nicht, ich muss leider zugeben, dass mir verschiedene Denkansätze gar nicht bewusst waren, weil ich es nicht im Team anwendete und ich habe noch immer gewisse Hemmungen dabei.
Hier ist es extrem hilfreich Teil eines Teams zu sein, welches eine außerordentliche Expertise einbringt und so zu einer hilfreichen Verwendung des Tools geradezu anregt.
# Ein Team hat verschiedene Herangehensweisen
Bei der Pflege eines zentralen Repository muss jedes Teammitglied sich zunächst das zentrale Repository „clonen“, das heißt sich den aktuellen Stand von dem zentralen runterladen.
git clone http://name.git
Erst jetzt sollten Änderungen durchgeführt werden.
Hierfür sollte allerdings ein separater Branch bemüht werden.
git branch
Eine Vereinbarung nach den erfolgten Änderungen
betrifft die Namensgebung, die Verwendung eines Templates
####
Die Realität sagt mir aber, dass ich regelmäßig an meinen Projekten arbeite, ohne mir viele Gedanken über welche Bezeichnungen, Namensgebungen o.ä. zu machen.
Daher gehe ich bei Bedarf in das Verzeichnis und stelle erstmal den Status fest.
git status
Welche Probleme treten auf bzw. können auftreten?
1.) Sollen Änderungen rückgängig gemacht werden, dann sollte
git discard
verwendet werden.
2.) Wenn mehrere Teammitglieder Änderungen an einer Datei durchführen, dann kommt es zu Konflikten in denen ein manuelles Eingreifen notwendig wird. Ein Vergleich beider Dateistände kann hier helfen.
git diff