Das Örtchen RSS-Feed
Suchen
Blog
Ähnliche Beiträge
Neueste Kommentare
Neueste Einträge
Populäre Einträge
Tagwolke
addon auswertung barcamp blog bug cms cms made simple datenkrake drupal feed film firefox frickeln friday gewinnspiel hardware how-to individualisierung meinung mmo modul nas php problem rss se7en server sicherheit sicherung software spiel teil theme trailer unterhaltung update windows windows 7 wordpress wow
Monatsarchiv

Git: Repository geclont, Änderungen gemacht und nun?

Nachdem ich mit TortoiseGit (meinem neuen GUI-Client für Git) ein Repository von Github geclont und danach die Änderungen an einer Datei mit Beyond Compare 3 optisch ansprechend kontrolliert habe, wollte ich die weitere Vorgehensweise testen. Hierbei habe ich als einfaches Szenario angedacht, daß sich zwei verschiedene Dateien geändert haben und ein Ordner hinzugekommen ist. Um die Schwierigkeit etwas anzuheben, wollte ich die Datei-Änderungen separat versionieren und der neue Ordner sollte ignoriert werden.

Begriffe

Der Einsatz einer verteilten Versionsverwaltung wie Git zusammen mit einem zentralen Repository auf Github bietet eine große Flexibilität bei der Arbeitsweise, aber auch die Notwendigkeit einige Begriffe zu trennen.

Das Repository auf Github werde ich fortan Quell-Repository nennen. Im Gegensatz hierzu gibt es das lokale Repository, welches durch das Clonen entstanden ist. Spricht man von committing a change (Commit), so betrifft dies nur die Versionierung der Änderungen im lokalen Repository. Spricht man hingegen von sharing that change, so meint man den Push vom lokalen Repository in das Quell-Repository.

Außerdem gibt es das Arbeitsverzeichnis, in welches das Quell-Repository geclont wurde. Innerhalb dieses Arbeitsverzeichnisses befindet sich auf oberster Ebene das versteckte Verzeichnis .git, welches ich fortan .git-Verzeichnis nennen werde.

Aktuellsten Stand abrufen

Spätestens vor jedem Commit sollte man den aktuellsten Stand des Quell-Repositorys abrufen. Hierfür hat man bei einem rechten Mausklick auf das Arbeitsverzeichnis unter TortoiseGit die beiden Punkte Pull und Fetch. Nach dem was ich in der Hilfe von TortoiseGit gelesen habe, erscheint mir ein Pull sinnvoller, da hierbei alle Änderungen des Quell-Repositorys mit den Änderungen im lokalen Repository zusammengefügt werden (merging). Dieser verschmolzene Stand befindet sich aber erst einmal nur im lokalen Repository.

Sinnvollerweise sollte bei der Remote-Quelle origin ausgewählt sein (was aber Standard ist), da wir ja den aktuellsten Stand unseres Quell-Repositorys abrufen wollen.

Geänderte Dateien feststellen

Als nächstes wollte ich testweise überprüfen, welche Dateien ich geändert bzw. hinzugefügt hatte. Hierzu macht man einfach wieder einen rechten Mausklick auf das Arbeitsverzeichnis und klickt TortoiseGit -> Diff. Im neuen Fenster (Fenster 1) sollte links unten der Haken bei "Show unversioned files" gesetzt sein. Nun sollten darüber zuerst die "Modified Files" und darunter die "Not Versioned" Files auftauchen. Möchte man für eine der modifizierten Dateien die genauen Änderungen erfahren, so geht dies mit einem rechten Mausklick und dann Compare with base. Da wir die Änderungen aber schon kannten, verlassen wir die Anzeige einfach wieder mit OK.

Verzeichnis ignorieren - Versuch 1

Zunächst wollte ich, daß der neue Unterordner in meinem Arbeitsverzeichnis von Git ignoriert wird. Hierfür probierte ich nachfolgende Vorgehensweise:

  1. Rechter Mausklick auf das neue Verzeichnis
  2. TortoiseGit -> Add to ignore list
  3. Der Ordnername erscheint als Auswahl, diesen anklicken

Starten wir nun erneut einen Diff auf das Arbeitsverzeichnis, so tauchen keine neuen Dateien mehr auf. Allerdings wird eine weitere geänderte Datei angezeigt, nämlich die Datei .gitignore in der die ignorierten Dateien und Verzeichnisse erfasst werden. Nach etwas Recherche war mir klar, daß dies die falsche Lösung für mich war, da der Ignore in meinem Fall zwar Projekt-spezifisch war, aber nur für meine lokale Installation gelten soll.

Verzeichnis ignorieren - Versuch 2

In meinem zweiten Versuch entschied ich mich für die auf Github Repo exclude genannte Variante. Hierfür öffnete ich die Datei .gitignore im Arbeitsverzeichnis und im .git-Verzeichnis im Unterordner info die Datei exclude mit meinem bevorzugten Editor Notepad++. Die durch den ersten Versuch entstandene Zeile aus der Datei .gitignore kopierte ich einfach ans Ende der Datei exclude, jedoch ohne diese zu löschen. Danach speicherte ich die Änderungen und beendete Notepad++ wieder.

Datei wiederherstellen

Die unerwünschte Änderung der Datei .gitignore wollte ich zu einer testweisen Wiederherstellung aus meinem lokalen Repository nutzen. Dies geht flott mittels rechtem Mausklick auf die Datei und TortoiseGit -> Revert.

Commit

Bei einem erneuten Diff auf das Arbeitsverzeichnis hatte ich nun den gewünschten Zustand, daß nur noch die beiden wirklichen Datei-Änderungen und keine Änderung in der Datei .gitignore oder gar neue Dateien angezeigt wurden. Also drückte ich Commit (anstatt von OK), um die Änderungen für die erste Datei in mein lokales Repository einzupflegen.

Ein neues Fenster für den Commit (Fenster 2) öffnet sich und zeigt einen großen Bereich 1 für eine Änderungs-Meldung (Message) und einen Bereich 2 für die von Änderungen betroffenen Dateien (Changes made) an. In Bereich 2 kann man sich durch einen Doppelklick auf die Datei einen Diff anzeigen lassen.

Ich entfernte in Bereich 2 den Haken vor der Datei, deren Änderungen erst in einem zweiten Commit in meinem lokalen Repository landen sollten, gab in Bereich 1 eine sinnvolle Message ein und startete den Commit mittels OK. Hierbei öffnete sich ein neues Fenster Git Command Progress (Fenster 3), welches ich nach Erscheinen der Meldung Success (Erfolg) mittels Close (ohne Push) schloss.

Danach landete ich wieder in Fenster 1 und drückte Refresh. Wie erwartet erschien nun nur noch die gerade beim Commit deselektierte Datei. Also klickte ich erneut Commit an, gab meine Message für diese Änderung ein und drückte OK.

Push

Direkt nach diesem zweiten Commit, nutzte ich die Möglichkeit für einen Push in Fenster 3. Dies ginge aber auch per rechtem Mausklick auf das Arbeitsverzeichnis TortoiseGit -> Push. Wichtig schien mir hier nur die Einstellung Remote: origin zu sein, welche aber sowieso Standard ist. Mit OK bestätigen und bei Success das Fenster mit Close schliessen (ohne Pull).

Hiernach wird Fenster 1 wieder angezeigt. Nach einem Refresh sollten dort keine Dateien mehr angezeigt werden und somit kann das Fenster mit OK geschlossen werden.

Fazit

Ein kurzer Login auf Github und eine Sichtung der Commit-Historie unseres Quell-Repositorys zeigte, daß die Änderungen beider Commits ordnungsgemäß übertragen wurden und einzeln vorhanden sind. Mir ist klar, daß es mit TortoiseGit auch etwas einfachere Vorgehensweisen (Beispiel 1 und Beispiel 2) gibt, aber die beschriebene Variante erschien mir die verständlichste und logischste zu sein. Oder kennt jemand einen besseren Weg?

Hallo! Bist du neu hier? Dann abonniere doch den RSS-Feed dieses nicht mehr ganz so stillen Örtchens, um über meine geistigen Ergüsse auf dem Laufenden zu bleiben. Alternativ besteht auch die Möglichkeit, sich von FeedBurner per E-Mail über meine Ausscheidungen benachrichtigen zu lassen.

Kommentar hinzufügen

(If you're a human, don't change the following field)
Your first name.
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Der Inhalt dieses Feldes wird öffentlich zugänglich angezeigt, aber als nofollow markiert.
Hinweis

Kommentare beleben den Blog! Ich freue mich über jeden Kommentar. Du kannst hier offen Deine Meinung zum Artikel sagen, aber bitte beachte die Netiquette und vermeide es andere zu beleidigen.

Bitte unterlasst es die Kommentare zu SEO-Zwecken zu missbrauchen. Kommentare mit Links, die nicht zu Blogs führen (oder zu Blogs mit Grauzonen-Themen) und/oder Keywords als Namen verwenden und/oder Links im Kommentarbereich enthalten, sind nicht erwünscht!

Möchtest Du mir einen Blog-Artikel schmackhaft machen, dann schreib die URL ohne Link-Tag und ohne http(s):// in den Kommentarbereich und ich werde diesen bei Gefallen verlinken.

Die ersten vier Kommentare (mit den gleichen Daten bei Name, E-Mail und Blog) landen vor der Veröffentlichung in meiner Freigabe-Warteschlange und ich behalte mir das Recht vor, Kommentare entsprechend dieser Regeln anzupassen oder zu löschen!