Git: Kurzanleitung „Fit für Git“ ;-)

Motivation

„Git ([ɡɪt], engl. Blödmann) ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die ursprünglich für die Quellcode-Verwaltung des Linux-Kernels entwickelt wurde.“ (http://de.wikipedia.org/wiki/Git)

Jeder der Software entwickelt, stellt irgendwann fest, dass eine Versionsverwaltung sinnvoll ist. Ohne eine Anspruch auf Vollständigkeit zu erheben, gibt es meist folgende Gründe: alte Versionsstände zurückspielen, Branches (Zweige der Entwicklung) zu eröffnen, oder, um im Team zu arbeiten.

Neben Git gibt es noch andere, freie, VCS (Version Control Systems). Populär sind unter anderem CVS und Subversion. Wenn man die Szene betrachtet, fällt auf, dass der Trend immer mehr in Richtung Git geht.

Git bietet, wie auch CVS oder Subversion, Clients für alle möglichen Betriebssysteme herunterladen, u.a. Windows, Linux, Solaris, Mac OS X.

 

Arbeitsweise

 

Philosophie

Git ist dezentral (distributed) und unterscheidet sich von traditionellen, zentral verwalteten Programmen, wie etwa CVS oder Subversion, dadurch,  dass kein zentraler Server benötigt wird. Ein Distributed VCS-System, wie Git, checkt im Gegensatz zu zentralen VCS-Systemen alle Dateien und Verwaltungsinformationen (Historie etc.) aus.

 

Vergleich mit CVS und Subversion

Ich habe mit einige Meinungen im Internet herausgepickt, die, teilweise subjektiv, für eine Verwendung von Git sprechen:

• Hat sich auch in großen Projekten bewährt (Linux-Kernel, Xorg, VLC, etc.)
• Trend spricht für Git: Anzahl der verfügbaren Git-Repositories steigt stark an
• Offline-Arbeiten immer möglich, da dezentral, d.h. es wird nach dem Erstellen der Arbeitskopie kein Zugriff mehr notwendig ist, alle Informationen sind in der Arbeitskopie
• Schneller als CVS oder Subversion, da man vorwiegend lokal arbeitet
• Mergen von Branches ist bei Subversion teilweise problematisch
• etc.

Die letzte aktuelle Git-Version (10.12.2012) lautet 1.8.0.2.

 

Git Workflow

Wenn man mit Git ein Verzeichnis unter Versionskontrolle stellen will, führt man folgende Schritte durch:

1. Erstellen eines Verzeichnisses, das zum Beispiel dem Projektnamen entspricht.
2. In das Verzeichnis wechseln und unter Git Versionskontrolle stellen (git init)

Damit hat man automatisch folgende Struktur geschaffen:

 

Ein Verzeichnis (Arbeitsbereich, Workspace), eine Staging-Area (Index) und ein lokales Git-Repository. Dateien aus dem Verzeichnis können in die Staging-Area verschoben werden (git add). Dateien aus der Staging-Area können in das lokale Git-Repository verschoben werden (git commit).

Alle Änderungen werden im Arbeitsbereich durchgeführt und haben zunächst keinen Einfluß auf die Git-Verwaltung, d.h. die Staging-Area und der Repository-Inhalt bleibt unverändert.

Die Reihenfolge ist also: Änderung(en) durchführen > git add > git commit

 

Wo ist der Server ?

Da Git dezentral arbeitet, ist ein Server nicht notwendig. Trotzdem kann man natürlich ein Git-Remote-Repository einrichten, also eine Instanz, die als Server fungiert und auf die ein lokales Git-Repository referenzieren kann.

Man kann von einem Server eine Kopie des Repositores in das lokale Git-Repository herunterladen (auschecken), dazu dient der Befehl „git pull“. Anschließend arbeitet man auf dem lokalen Git-Repository weiter. Will man die Änderungen auf den Server hochladen (einchecken), dann ist das mit dem Befehl „git push“ möglich.

Für den Fall, dass man ein Git-Remote-Repository einbindet, wird die Infrastruktur wie folgt erweitert:

 

Installation Git

Die grundsätzliche Installation von Git, egal, ob Server oder Client, wird im Folgenden für Linux- und Windows-Systeme beschrieben.

 

Linux

Auf Ubuntu oder Debian:

sudo apt-get install git-core python-setuptools

 

Windows

Git kann man direkt von http://git-scm.com/downloads herunterladen.

 

Applikationen

 

Linux

Unter Linux hat man das Terminal mit einer Shell (z.B. Bash) und kann git direkt aufrufen. Der Pfad auf git ist defaultmäßig bereits nach der Installation gesetzt.

Als Repository-Browser kann man „gitg“ verwenden.

 

Windows

Git-Bash

Nach der Installation erhält man die Git-Bash, eine Shell, von der aus alle Git-Befehle aufgerufen werden können.

Windows-Explorer

Zusätzlich werden im Windows-Explorer Kontext-Menus hinzugefügt.

 

Konfiguration Git

Der erste Schritt, bei der Verwendung von Git auf einem Rechner, sollte die Einrichtung des Users sein. Dieser erscheint in allen Änderungen und macht ihn identifizierbar (Rückfragen etc.).

Alle Befehle werden auf der Git-Bash ausgeführt!

Die Befehle dazu lauten:

<code>git config --global user.name </code>"Your Name"<code></code>

<code>git config --global user.email your@email.com<br /></code>

Siehe auch: http://git-scm.com/book/en/Customizing-Git-Git-Configuration

 

Lokal arbeiten

Auf Client-Seite, also lokal, arbeitet man mit einer Arbeitskopie. Ob diese Arbeitskopie lokal bleiben soll, durch Auschecken von einem Server heruntergeladen, oder später auf irgendeinen Server hochgeladen werden soll, ist erst einmal sekundär.

 

Projekte erstellen 

Neuerstellung

Will man ein neues Projekt erstellen, dann verwendet man die Option „init“. Man erstellt ein Verzeichnis, wechselt dahin und gibt den Befehl „git init“ ein. Der Verzeichnisname entspricht damit dem Projektnamen

Beispiel:

mkdir testprojekt

cd testprojekt

git init

 

Vorhandenes Verzeichnis in ein Git-Repository umwandeln (lokal)

Wenn man bereits ein Projekt hat, kann man mit dem „init“ Befehl ein lokales Git-Repository erstellen. Es werden alle Dateien des entsprechenden Verzeichnisses direkt in das Repository übernommen.

Man wechselt in das entsprechende Projekt-Verzeichnis und ruft in der Git-Bash den Befehl „git init“ auf. 

 

Repository von einem Server auschecken

Will man ein Projekt, etwa aus dem Internet lokal speichern und weiterbearbeiten, dann „klont“ man es 😉 Man erstellt damit eine lokale Arbeitskopie bzw. ein lokales Repository.

 

Änderungen durchführen

Workflow

 

Dateien hinzufügen

Man wechselt in das entsprechende Arbeitsverzeichnis und erstellt eine Datei, z.B. mit einem Texteditor.

Danach schiebt man diese Datei in die Staging-Area, mit dem Befehl:

git add

Will man mehrere Dateien gleichzeitig hinzufügen, kann man auch Joker „*“ verwenden, z.B.

git add *

Dateien, die im aktuellen Repository noch nicht im Index (Staging-Area) stehen, ermittelt man mit dem Befehl „git status“.

 

Dateien ändern

Sobald eine Datei unter Git verwaltet wird, wird sie „getracked“. Damit Änderungen im lokalen Git-Repository landen, müssen sie vorher in die Staging-Area verschoben werden. Das geschieht durch den Befehl „git add Datei“, auch wenn die Datei bereits in der Git-Versionsverwaltung existiert!

Der Befehl „git add“ macht Änderungen in einer Datei in der Staging-Area bekannt!

Der Befehl „git status“ zeigt u.a. den aktuellen Zustand der Staging-Area an, d.h. welche Dateien befinden sich darin und welche Dateien können comitted werden.

 

Dateien löschen

Mit dem Befehl „git rm“ kann man Dateien löschen:

git rm dummy.txt

Die Änderung ist dann automatisch in der Staging-Area und kann mit einem commit in das lokale Git-Repository verschoben werden.

 

Dateien umbenennen

Mit dem Befehl „git mv“ kann man Dateien löschen:

git mv alterName.txt neuerName.txt

Die Änderung ist dann automatisch in der Staging-Area und kann mit einem commit in das lokale Git-Repository verschoben werden.

 

Änderungen im lokalen Git-Repository bekanntmachen

Um Änderungen von der Staging-Area in das lokale Git-Repository zu übertragen, verwendet man den Befehl „git commit“.

git commit

git commit –m Kommentar

 

Änderungen rückgängig machen

 

Task	Befehl	Workspace	Index (I)	Repository (R)
Datei anlegen	touch Datei.txt	Datei.txt V1	–	–
Datei in Staging-Area verschieben	git add Datei.txt	Datei.txt V1	Datei.txt V1	–
Datei in Repository schieben	git commit	Datei.txt V1	Datei.txt V1	Datei.txt V1
Änderungen in Staging-Area rückgängig machen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git add Datei.txt	Datei.txt V2	Datei.txt V2	Datei.txt V1
	git reset	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git checkout – Datei.txt	Datei.txt V1	Datei.txt V1	Datei.txt V1
Änderungen im Workspace rückgängig machen	touch Datei2.txt	Datei.txt V2 Datei2.txt V1	Datei.txt V1	Datei.txt V1
	clean –f	Datei.txt V1	Datei.txt V1	Datei.txt V1
Workspace auf Stand der Staging-Area zurücksetzen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git checkout – Datei.txt	Datei.txt V1	Datei.txt V1	Datei.txt V1
Workspace und Staging-Area auf aktuellen Stand des Repositories zurücksetzen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git add Datei.txt	Datei.txt V2	Datei.txt V2	Datei.txt V1
	git reset –hard	Datei.txt V1	Datei.txt V1	Datei.txt V1
Workspace, Staging-Area und Repository auf vorigen Stand (seit dem letzten Commit) zurücksetzen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git commit –a	Datei.txt V2	Datei.txt V2	Datei.txt V2
	git reset –hard HEAD~1 (Hinweis: HEAD~2 setzt auf den vorletzten Commit zurück etc.)	Datei.txt V1	Datei.txt V1	Datei.txt V1

 

Änderungen anschauen:

• git status: zeigt Änderungen im Workspace und in der Staging-Area an, die durchzuführen sind.
• git log: zeigt die Commits im Repository an
• git diff: zeigt die Unterschiede zwischen Workspace und Index (Staging-Area)
• git diff HEAD: zeigt die Änderungen zwischen Workspace und Repository

 

Hochladen/Einchecken

Will man das lokale Git-Repository auf einen Server laden, führt man den Befehl „push“ aus. Beim erstenmal muss man mitteilen in welchen Branch auf dem „Hauptrepository“ die Arbeitskopie landen soll:

git push origin master

 

Versionierung/Tags

Mit dem Befehl „git tag -a“ kennzeichnet man einen Commit, also einen Stand im lokalen Git-Repository.

Beispiel:

git tag -a v1.0.0 -m „Creating the first official version.“

Will man sich vorher überzeugen, welche Dateien in den Tag aufgenommen werden, kann man den Befehl „git ls-files“ verwenden.

Um die vorhandenen Tags aufzulisten, kann man den Befehl „git tag“ verwenden. Danach kann man sich mit „git tag –v“ Details zu einem Tag anschauen:

git tag –v v1.0.0

Mit dem Befehl „git show“ kann man sich die Änderungen im lokalen Repository anschauen:

git show v1.0.0

Um einen bestimmten, getaggten Versionsstand in der Staging-Area und im Workspace auszuchecken, kann man „git checkout“ verwenden:

git checkout v1.0.0

Tags kann man auch löschen, hierzu dient der Befehl „git tag –d“

git tag –d v1.0.0

Für die Synchronisation mit einem remote Git-Repository dienen die Befehle

git push

git push –tags

git fetch

git fetch –tags

 

Entwicklungszweige/Branches

Ein Entwicklungszweig (Branch) ist eine Verzweigung in einem Projekt, die parallel zum bestehenden Hauptzweig erstellt wird. Hat man mehrere Entwicklungszweige zu pflegen, wie beispielsweise stable oder testing, kann man sich der Branches bedienen. Um bestehende Branches anzuzeigen, gibt man den Befehl „git branch“ ein. 

 

Will man einen neuen Branch anlegen, verwendet man den Befehl „git branch“:

git branch Branchname

 

Beispiel:

git branch testing

 

Will man zu einem bestimmten Branch wechseln, verwendet man den Befehl „git checkout“:

git checkout Branchname

 

Beispiele:

git checkout testing

git checkout master

 

Um einen Branch zu löschen, verwendet man den Befehl

git branch –d Branchname

 

Um einen Branch auf ein bekanntes remote Git-Repository zu schieben, dient der Befehl:

git push origin Branchname

 Beispiel:

git push origin testing

 

Um den Branch auf dem remote Git-Repository wieder zu löschen, dient der Befehl:

git push origin :Branchname

 Beispiel:

git push origin :testing

 

Um sich nur Branches im lokalen Git-Repository anzuzeigen, verwendet man den Befehl:

git branch –a

Um sich nur Branches im remote Git-Repository anzuzeigen, verwendet man den Befehl:

git branch –r

 

Dateien im Workspace ignorieren

Die Datei „.gitignore“ gibt vor, welche Dateien von Git ignoriert werden sollen. Man kann diese Datei im Hauptverzeichnis des Workspaces anlegen, aber auch in den Unterverzeichnissen.

 

Beispiel einer Datei „.gitignore“:

# Can ignore specific files

.DS_Store

 

# Use wildcards as well

*~

*.swp

 

# Can also ignore all directories and files in a directory.

tmp/**/*

 

Man kann auch eine .gitignore Datei im HOME Verzeichnis anlegen. Sie betrifft dann alle Repositories, sofern sie durch folgenden (globalen) Git-Befehl aktiviert wird:

git config –global core.excludesfile ~/.gitignore

 

Server-Funktionalität einrichten

Wie bereits erwähnt handelt es sich bei Git um eine Peer-To-Peer-Lösung, ein Server ist also grundsätzlich nicht erforderlich. Aber was hält uns davon ab ein „Hauptrepository“ einzurichten, das zentral aller Versionsstände aller Projektes speichert?

Es gibt viele Möglichkeiten ein „Hauptrepository“ zu teilen, siehe auch: „8 ways to share your git repository“.

 

Der von mir präferierte Weg sieh wiefolgt aus…

Benutzer und Gruppen einrichten

Es ist sinnvoll auf dem Server eine Art-Git-Administrator einzurichten, z.B. den User „git“, der für alle zentralen Repository-Aufgaben zuständig ist. Zudem sollte man eine (oder mehrere) Gruppen einrichten, die Zugriff auf die Repositories erhalten, beispielsweise die Gruppe „developers“.

1. Einrichten eines User „git“ und einer Gruppe „git“
   sudo adduser git
2. Einrichten der Gruppe „developers“
   sudo addgroup developers
3. Hinzufügen alle Accounts, die zur Gruppe „devlopers“ gehören sollen
   vi /etc/group

 

Zentrales Repository einrichten

Ein zentrales Git-Repository auf einem Server, wird wie ein lokales Git-Repository eingerichtet. Für alle Aufgaben im zentralen Git-Repository verwenden wir den zuvor angelegten Benutzer „git“.

Man legt für diesen User ein Hauptverzeichnis „repo“ an unter dem alle Repositories als Unterverzeichnisse abgelegt werden.

Beispiel:

su – git

mkdir ~/repositories

cd repositories

Danach erstellt man für jedes Projekt ein leeres Unterverzeichnis und ordnet es der entsprechenden Gruppe zu.

mkdir testprojekt.git

sudo chgrp developers testprojekt.git

sudo chmod g+rws    (Sticky-Bit nicht vergessen)

…

cd testprojekt.git

Hinweis: Es ist weit verbreitet, das zentrale Repositories mit dem Suffix „.git“ zu versehen, um sie als Git-Repositories kenntlich zu machen.

Danach initialisiert man das zentrale Repository mit dem Befehl „init“ und dem Schalter „bare“: Damit vermeidet man, dass eine Arbeitskopie erstellt wird und damit unnötige Git-Hilfsdateien erzeugt werden. Das zentrale Repository ist dann auch nicht dafür geeignet, direkt damit zu arbeiten. Man muss vorher das entsprechende Projekt auf einem Client auschecken, also ein lokales Git-Repository erzeugen. Zusätzlich wird noch der Schalter „—shared“ mitgegeben, damit können alle Gruppenmitglieder auf das Repository zugreifen.

sudo git init –bare –shared

 

Lokales Repository mit dem Hauptrepository auf dem Server verlinken

Ein lokales Repository kann nun zum zentralen Repository übertragen werden. Dazu wechselt man auf dem Client in das lokale Repository und setzt zunächst das origin:

cd testprojekt

git remote add origin ssh://:/~/repos/testprojekt.git

 

Lokales Repository zum Server hochladen (Einchecken)

Damit wird dem lokalen Repository mitgeteilt, auf welchem Server sich das „Original“ bzw. die zentrale „Quelle“, also das Hauptrepository befindet.

Danach schiebt man den Inhalt des lokalen Repositories auf den Server mit „push“:

git push origin master

Beim ersten mal muss der Hauptbranch „master“ mitgegeben werden.

Man kann auch von einem bestimmten Branch (Entwicklungszeig) im lokalen Repository auf einen bestimmten Branch im Hauptrepository „pushen“:

git push origin :

Beispiel: git push origin master:master

Hier kann auch ein komplett neuer Remote-Branch angelegt werden, indem master:neuerBranchName verwendet wird.

 

Hauptrepository (Server) auf Client auschecken

Um ein Hauptrepository auf einem Client auszuchecken, ist folgender Befehl notwendig:

git clone ssh://@/home/user/development/git/repo

Beispiel:

git clone ssh://juergen@aspire/~git/repositories/testprojekt.git

oder

git clone @:~git/repositories/

Beispiel:

git clone juergen@aspire:~git/repositories/testprojekt.git

Es wird dann auf dem Client ein Verzeichnis ohne den Suffix „.git“ angelegt

 

 

Anhang

 

Übersicht Workflow

 

 

Links

Git Homepage: http://git-scm.com

Ubuntu-Git Wiki:http://wiki.ubuntuusers.de/Git

http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository  

Homepdate Git for Windows: http://msysgit.github.com

Michael’s Git Tutorial – Setting Up a Git Server:  http://www.youtube.com/watch?v=SyMkLQLC3Kg  

This post is not available in english! Sorry!

 

Git: Kurzanleitung "Fit für Git" ;-)

Motivation

„Git ([ɡɪt], engl. Blödmann) ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die ursprünglich für die Quellcode-Verwaltung des Linux-Kernels entwickelt wurde.“ (http://de.wikipedia.org/wiki/Git)

Jeder der Software entwickelt, stellt irgendwann fest, dass eine Versionsverwaltung sinnvoll ist. Ohne eine Anspruch auf Vollständigkeit zu erheben, gibt es meist folgende Gründe: alte Versionsstände zurückspielen, Branches (Zweige der Entwicklung) zu eröffnen, oder, um im Team zu arbeiten.

Neben Git gibt es noch andere, freie, VCS (Version Control Systems). Populär sind unter anderem CVS und Subversion. Wenn man die Szene betrachtet, fällt auf, dass der Trend immer mehr in Richtung Git geht.

Git bietet, wie auch CVS oder Subversion, Clients für alle möglichen Betriebssysteme herunterladen, u.a. Windows, Linux, Solaris, Mac OS X.

 

Arbeitsweise

 

Philosophie

Git ist dezentral (distributed) und unterscheidet sich von traditionellen, zentral verwalteten Programmen, wie etwa CVS oder Subversion, dadurch,  dass kein zentraler Server benötigt wird. Ein Distributed VCS-System, wie Git, checkt im Gegensatz zu zentralen VCS-Systemen alle Dateien und Verwaltungsinformationen (Historie etc.) aus.

 

Vergleich mit CVS und Subversion

Ich habe mit einige Meinungen im Internet herausgepickt, die, teilweise subjektiv, für eine Verwendung von Git sprechen:

• Hat sich auch in großen Projekten bewährt (Linux-Kernel, Xorg, VLC, etc.)
• Trend spricht für Git: Anzahl der verfügbaren Git-Repositories steigt stark an
• Offline-Arbeiten immer möglich, da dezentral, d.h. es wird nach dem Erstellen der Arbeitskopie kein Zugriff mehr notwendig ist, alle Informationen sind in der Arbeitskopie
• Schneller als CVS oder Subversion, da man vorwiegend lokal arbeitet
• Mergen von Branches ist bei Subversion teilweise problematisch
• etc.

Die letzte aktuelle Git-Version (10.12.2012) lautet 1.8.0.2.

 

Git Workflow

Wenn man mit Git ein Verzeichnis unter Versionskontrolle stellen will, führt man folgende Schritte durch:

1. Erstellen eines Verzeichnisses, das zum Beispiel dem Projektnamen entspricht.
2. In das Verzeichnis wechseln und unter Git Versionskontrolle stellen (git init)

Damit hat man automatisch folgende Struktur geschaffen:

 

Ein Verzeichnis (Arbeitsbereich, Workspace), eine Staging-Area (Index) und ein lokales Git-Repository. Dateien aus dem Verzeichnis können in die Staging-Area verschoben werden (git add). Dateien aus der Staging-Area können in das lokale Git-Repository verschoben werden (git commit).

Alle Änderungen werden im Arbeitsbereich durchgeführt und haben zunächst keinen Einfluß auf die Git-Verwaltung, d.h. die Staging-Area und der Repository-Inhalt bleibt unverändert.

Die Reihenfolge ist also: Änderung(en) durchführen > git add > git commit

 

Wo ist der Server ?

Da Git dezentral arbeitet, ist ein Server nicht notwendig. Trotzdem kann man natürlich ein Git-Remote-Repository einrichten, also eine Instanz, die als Server fungiert und auf die ein lokales Git-Repository referenzieren kann.

Man kann von einem Server eine Kopie des Repositores in das lokale Git-Repository herunterladen (auschecken), dazu dient der Befehl „git pull“. Anschließend arbeitet man auf dem lokalen Git-Repository weiter. Will man die Änderungen auf den Server hochladen (einchecken), dann ist das mit dem Befehl „git push“ möglich.

Für den Fall, dass man ein Git-Remote-Repository einbindet, wird die Infrastruktur wie folgt erweitert:

 

Installation Git

Die grundsätzliche Installation von Git, egal, ob Server oder Client, wird im Folgenden für Linux- und Windows-Systeme beschrieben.

 

Linux

Auf Ubuntu oder Debian:

sudo apt-get install git-core python-setuptools

 

Windows

Git kann man direkt von http://git-scm.com/downloads herunterladen.

 

Applikationen

 

Linux

Unter Linux hat man das Terminal mit einer Shell (z.B. Bash) und kann git direkt aufrufen. Der Pfad auf git ist defaultmäßig bereits nach der Installation gesetzt.

Als Repository-Browser kann man „gitg“ verwenden.

 

Windows

Git-Bash

Nach der Installation erhält man die Git-Bash, eine Shell, von der aus alle Git-Befehle aufgerufen werden können.

Windows-Explorer

Zusätzlich werden im Windows-Explorer Kontext-Menus hinzugefügt.

 

Konfiguration Git

Der erste Schritt, bei der Verwendung von Git auf einem Rechner, sollte die Einrichtung des Users sein. Dieser erscheint in allen Änderungen und macht ihn identifizierbar (Rückfragen etc.).

Alle Befehle werden auf der Git-Bash ausgeführt!

Die Befehle dazu lauten:

<code>git config --global user.name </code>"Your Name"<code></code>

<code>git config --global user.email your@email.com<br /></code>

Siehe auch: http://git-scm.com/book/en/Customizing-Git-Git-Configuration

 

Lokal arbeiten

Auf Client-Seite, also lokal, arbeitet man mit einer Arbeitskopie. Ob diese Arbeitskopie lokal bleiben soll, durch Auschecken von einem Server heruntergeladen, oder später auf irgendeinen Server hochgeladen werden soll, ist erst einmal sekundär.

 

Projekte erstellen 

Neuerstellung

Will man ein neues Projekt erstellen, dann verwendet man die Option „init“. Man erstellt ein Verzeichnis, wechselt dahin und gibt den Befehl „git init“ ein. Der Verzeichnisname entspricht damit dem Projektnamen

Beispiel:

mkdir testprojekt

cd testprojekt

git init

 

Vorhandenes Verzeichnis in ein Git-Repository umwandeln (lokal)

Wenn man bereits ein Projekt hat, kann man mit dem „init“ Befehl ein lokales Git-Repository erstellen. Es werden alle Dateien des entsprechenden Verzeichnisses direkt in das Repository übernommen.

Man wechselt in das entsprechende Projekt-Verzeichnis und ruft in der Git-Bash den Befehl „git init“ auf. 

 

Repository von einem Server auschecken

Will man ein Projekt, etwa aus dem Internet lokal speichern und weiterbearbeiten, dann „klont“ man es 😉 Man erstellt damit eine lokale Arbeitskopie bzw. ein lokales Repository.

 

Änderungen durchführen

Workflow

 

Dateien hinzufügen

Man wechselt in das entsprechende Arbeitsverzeichnis und erstellt eine Datei, z.B. mit einem Texteditor.

Danach schiebt man diese Datei in die Staging-Area, mit dem Befehl:

git add

Will man mehrere Dateien gleichzeitig hinzufügen, kann man auch Joker „*“ verwenden, z.B.

git add *

Dateien, die im aktuellen Repository noch nicht im Index (Staging-Area) stehen, ermittelt man mit dem Befehl „git status“.

 

Dateien ändern

Sobald eine Datei unter Git verwaltet wird, wird sie „getracked“. Damit Änderungen im lokalen Git-Repository landen, müssen sie vorher in die Staging-Area verschoben werden. Das geschieht durch den Befehl „git add Datei“, auch wenn die Datei bereits in der Git-Versionsverwaltung existiert!

Der Befehl „git add“ macht Änderungen in einer Datei in der Staging-Area bekannt!

Der Befehl „git status“ zeigt u.a. den aktuellen Zustand der Staging-Area an, d.h. welche Dateien befinden sich darin und welche Dateien können comitted werden.

 

Dateien löschen

Mit dem Befehl „git rm“ kann man Dateien löschen:

git rm dummy.txt

Die Änderung ist dann automatisch in der Staging-Area und kann mit einem commit in das lokale Git-Repository verschoben werden.

 

Dateien umbenennen

Mit dem Befehl „git mv“ kann man Dateien löschen:

git mv alterName.txt neuerName.txt

Die Änderung ist dann automatisch in der Staging-Area und kann mit einem commit in das lokale Git-Repository verschoben werden.

 

Änderungen im lokalen Git-Repository bekanntmachen

Um Änderungen von der Staging-Area in das lokale Git-Repository zu übertragen, verwendet man den Befehl „git commit“.

git commit

git commit –m Kommentar

 

Änderungen rückgängig machen

 

Task	Befehl	Workspace	Index (I)	Repository (R)
Datei anlegen	touch Datei.txt	Datei.txt V1	–	–
Datei in Staging-Area verschieben	git add Datei.txt	Datei.txt V1	Datei.txt V1	–
Datei in Repository schieben	git commit	Datei.txt V1	Datei.txt V1	Datei.txt V1
Änderungen in Staging-Area rückgängig machen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git add Datei.txt	Datei.txt V2	Datei.txt V2	Datei.txt V1
	git reset	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git checkout – Datei.txt	Datei.txt V1	Datei.txt V1	Datei.txt V1
Änderungen im Workspace rückgängig machen	touch Datei2.txt	Datei.txt V2 Datei2.txt V1	Datei.txt V1	Datei.txt V1
	clean –f	Datei.txt V1	Datei.txt V1	Datei.txt V1
Workspace auf Stand der Staging-Area zurücksetzen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git checkout – Datei.txt	Datei.txt V1	Datei.txt V1	Datei.txt V1
Workspace und Staging-Area auf aktuellen Stand des Repositories zurücksetzen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git add Datei.txt	Datei.txt V2	Datei.txt V2	Datei.txt V1
	git reset –hard	Datei.txt V1	Datei.txt V1	Datei.txt V1
Workspace, Staging-Area und Repository auf vorigen Stand (seit dem letzten Commit) zurücksetzen	vi Datei.txt	Datei.txt V2	Datei.txt V1	Datei.txt V1
	git commit –a	Datei.txt V2	Datei.txt V2	Datei.txt V2
	git reset –hard HEAD~1 (Hinweis: HEAD~2 setzt auf den vorletzten Commit zurück etc.)	Datei.txt V1	Datei.txt V1	Datei.txt V1

 

Änderungen anschauen:

• git status: zeigt Änderungen im Workspace und in der Staging-Area an, die durchzuführen sind.
• git log: zeigt die Commits im Repository an
• git diff: zeigt die Unterschiede zwischen Workspace und Index (Staging-Area)
• git diff HEAD: zeigt die Änderungen zwischen Workspace und Repository

 

Hochladen/Einchecken

Will man das lokale Git-Repository auf einen Server laden, führt man den Befehl „push“ aus. Beim erstenmal muss man mitteilen in welchen Branch auf dem „Hauptrepository“ die Arbeitskopie landen soll:

git push origin master

 

Versionierung/Tags

Mit dem Befehl „git tag -a“ kennzeichnet man einen Commit, also einen Stand im lokalen Git-Repository.

Beispiel:

git tag -a v1.0.0 -m „Creating the first official version.“

Will man sich vorher überzeugen, welche Dateien in den Tag aufgenommen werden, kann man den Befehl „git ls-files“ verwenden.

Um die vorhandenen Tags aufzulisten, kann man den Befehl „git tag“ verwenden. Danach kann man sich mit „git tag –v“ Details zu einem Tag anschauen:

git tag –v v1.0.0

Mit dem Befehl „git show“ kann man sich die Änderungen im lokalen Repository anschauen:

git show v1.0.0

Um einen bestimmten, getaggten Versionsstand in der Staging-Area und im Workspace auszuchecken, kann man „git checkout“ verwenden:

git checkout v1.0.0

Tags kann man auch löschen, hierzu dient der Befehl „git tag –d“

git tag –d v1.0.0

Für die Synchronisation mit einem remote Git-Repository dienen die Befehle

git push

git push –tags

git fetch

git fetch –tags

 

Entwicklungszweige/Branches

Ein Entwicklungszweig (Branch) ist eine Verzweigung in einem Projekt, die parallel zum bestehenden Hauptzweig erstellt wird. Hat man mehrere Entwicklungszweige zu pflegen, wie beispielsweise stable oder testing, kann man sich der Branches bedienen. Um bestehende Branches anzuzeigen, gibt man den Befehl „git branch“ ein. 

 

Will man einen neuen Branch anlegen, verwendet man den Befehl „git branch“:

git branch Branchname

 

Beispiel:

git branch testing

 

Will man zu einem bestimmten Branch wechseln, verwendet man den Befehl „git checkout“:

git checkout Branchname

 

Beispiele:

git checkout testing

git checkout master

 

Um einen Branch zu löschen, verwendet man den Befehl

git branch –d Branchname

 

Um einen Branch auf ein bekanntes remote Git-Repository zu schieben, dient der Befehl:

git push origin Branchname

 Beispiel:

git push origin testing

 

Um den Branch auf dem remote Git-Repository wieder zu löschen, dient der Befehl:

git push origin :Branchname

 Beispiel:

git push origin :testing

 

Um sich nur Branches im lokalen Git-Repository anzuzeigen, verwendet man den Befehl:

git branch –a

Um sich nur Branches im remote Git-Repository anzuzeigen, verwendet man den Befehl:

git branch –r

 

Dateien im Workspace ignorieren

Die Datei „.gitignore“ gibt vor, welche Dateien von Git ignoriert werden sollen. Man kann diese Datei im Hauptverzeichnis des Workspaces anlegen, aber auch in den Unterverzeichnissen.

 

Beispiel einer Datei „.gitignore“:

# Can ignore specific files

.DS_Store

 

# Use wildcards as well

*~

*.swp

 

# Can also ignore all directories and files in a directory.

tmp/**/*

 

Man kann auch eine .gitignore Datei im HOME Verzeichnis anlegen. Sie betrifft dann alle Repositories, sofern sie durch folgenden (globalen) Git-Befehl aktiviert wird:

git config –global core.excludesfile ~/.gitignore

 

Server-Funktionalität einrichten

Wie bereits erwähnt handelt es sich bei Git um eine Peer-To-Peer-Lösung, ein Server ist also grundsätzlich nicht erforderlich. Aber was hält uns davon ab ein „Hauptrepository“ einzurichten, das zentral aller Versionsstände aller Projektes speichert?

Es gibt viele Möglichkeiten ein „Hauptrepository“ zu teilen, siehe auch: „8 ways to share your git repository“.

 

Der von mir präferierte Weg sieh wiefolgt aus…

Benutzer und Gruppen einrichten

Es ist sinnvoll auf dem Server eine Art-Git-Administrator einzurichten, z.B. den User „git“, der für alle zentralen Repository-Aufgaben zuständig ist. Zudem sollte man eine (oder mehrere) Gruppen einrichten, die Zugriff auf die Repositories erhalten, beispielsweise die Gruppe „developers“.

1. Einrichten eines User „git“ und einer Gruppe „git“
   sudo adduser git
2. Einrichten der Gruppe „developers“
   sudo addgroup developers
3. Hinzufügen alle Accounts, die zur Gruppe „devlopers“ gehören sollen
   vi /etc/group

 

Zentrales Repository einrichten

Ein zentrales Git-Repository auf einem Server, wird wie ein lokales Git-Repository eingerichtet. Für alle Aufgaben im zentralen Git-Repository verwenden wir den zuvor angelegten Benutzer „git“.

Man legt für diesen User ein Hauptverzeichnis „repo“ an unter dem alle Repositories als Unterverzeichnisse abgelegt werden.

Beispiel:

su – git

mkdir ~/repositories

cd repositories

Danach erstellt man für jedes Projekt ein leeres Unterverzeichnis und ordnet es der entsprechenden Gruppe zu.

mkdir testprojekt.git

sudo chgrp developers testprojekt.git

sudo chmod g+rws    (Sticky-Bit nicht vergessen)

…

cd testprojekt.git

Hinweis: Es ist weit verbreitet, das zentrale Repositories mit dem Suffix „.git“ zu versehen, um sie als Git-Repositories kenntlich zu machen.

Danach initialisiert man das zentrale Repository mit dem Befehl „init“ und dem Schalter „bare“: Damit vermeidet man, dass eine Arbeitskopie erstellt wird und damit unnötige Git-Hilfsdateien erzeugt werden. Das zentrale Repository ist dann auch nicht dafür geeignet, direkt damit zu arbeiten. Man muss vorher das entsprechende Projekt auf einem Client auschecken, also ein lokales Git-Repository erzeugen. Zusätzlich wird noch der Schalter „—shared“ mitgegeben, damit können alle Gruppenmitglieder auf das Repository zugreifen.

sudo git init –bare –shared

 

Lokales Repository mit dem Hauptrepository auf dem Server verlinken

Ein lokales Repository kann nun zum zentralen Repository übertragen werden. Dazu wechselt man auf dem Client in das lokale Repository und setzt zunächst das origin:

cd testprojekt

git remote add origin ssh://:/~/repos/testprojekt.git

 

Lokales Repository zum Server hochladen (Einchecken)

Damit wird dem lokalen Repository mitgeteilt, auf welchem Server sich das „Original“ bzw. die zentrale „Quelle“, also das Hauptrepository befindet.

Danach schiebt man den Inhalt des lokalen Repositories auf den Server mit „push“:

git push origin master

Beim ersten mal muss der Hauptbranch „master“ mitgegeben werden.

Man kann auch von einem bestimmten Branch (Entwicklungszeig) im lokalen Repository auf einen bestimmten Branch im Hauptrepository „pushen“:

git push origin :

Beispiel: git push origin master:master

Hier kann auch ein komplett neuer Remote-Branch angelegt werden, indem master:neuerBranchName verwendet wird.

 

Hauptrepository (Server) auf Client auschecken

Um ein Hauptrepository auf einem Client auszuchecken, ist folgender Befehl notwendig:

git clone ssh://@/home/user/development/git/repo

Beispiel:

git clone ssh://juergen@aspire/~git/repositories/testprojekt.git

oder

git clone @:~git/repositories/

Beispiel:

git clone juergen@aspire:~git/repositories/testprojekt.git

Es wird dann auf dem Client ein Verzeichnis ohne den Suffix „.git“ angelegt

 

 

Anhang

 

Übersicht Workflow

 

 

Links

Git Homepage: http://git-scm.com

Ubuntu-Git Wiki:http://wiki.ubuntuusers.de/Git

http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository  

Homepdate Git for Windows: http://msysgit.github.com

Michael’s Git Tutorial – Setting Up a Git Server:  http://www.youtube.com/watch?v=SyMkLQLC3Kg  

This post is not available in english! Sorry!

 

SSH: Shell-Login ohne Passwort auf Windows und Linux

Motivation

Ich habe ein kleines, bescheidenes Heimnetzwerk, mit Linux- und Windows-Rechnern. Darauf laufen die Betriebssysteme Ubuntu, Linux-Mint, Windows7 und Windows8. Unter Linux arbeite ich gerne auf Shell-Ebene, um administrative Aufgaben zu erledigen. Nun ist es ziemlich mühsam, sich jedesmal per Username/Passwort auf diesen Systemen remote einzuloggen. Wenn auf dem Ziel-System (aka Server) ein SSH–Daemon (aka Service) läuft, dann ist es auf Client-Seite ein Kinderspiel sich ohne diese lästige Abfrage auf dem Server einzuloggen, egal, ob es sich um einen Windows-Client, oder einen Linux-Client handelt. Warum sich also nicht die Mühe machen, alle Rechner seines Systems so zu konfigurieren, dass ein Auto-Login möglich ist. Man identifiziert sich dann nur nch einmalig auf einem Client, und kann auf alle anderen Rechner automatisch auf Shell-Ebene zugreifen.

 

Server installieren/konfigurieren

Linux 

OpenSSH ist auf Linux-Systemen als SSH-Server/Client weit verbreitet. Ich verwende in meinem Heimnetz ausschließlich Ubuntu bzw. Derivate von Ubuntu und werde deshalb im folgenden die Linux-Lösungen speziell dafür beschreiben.

Am einfachsten man installiert das Paket „ssh“, es enthält alle Programme für Client und Server. Geizhälse können auch nur den Server mit dem Paket „openssh-server“ installieren.

sudo apt-get install ssh

 

Die Installation und Konfiguration erfolgt automatisch, nach Abschluss sollte man einen Listener auf Port sehen:

sudo lsof -i (Alternativ: sudo netstat -lptu oder sudo netstat -tulpn)

 

 

Im Beispiel wird als PID die Nummer 8331 angegeben. Will man noch wissen, auf welchem Port der sshd horcht, hilft der folgende Befehl weiter:

sudo netstat -pan | grep 

 

Im o.g. Beispiel wäre also das SSH Standardport „22“ durch den SSH-Daemon belegt.

Alternativ kann man mit folgendem Befehl den Status des Daemons abfragen:

/etc/init.d/ssh status 

 

Jeder Benutzer, der Zugang auf den Server erhalten soll, muss einen Account besitzen. Bei den meisten Linux-Distributionen geschieht das, auf der Kommandozeile, mit dem Befehl „adduser“. Will man also beispielsweise den Benutzer „rainer“ einrichten, dann kann man folgenden Befehl eingeben:

sudo adduser rainer<br /><br />

Damit wäre die Installation/Konfiguration auf einem Linux-System erledigt.

 

Windows 

Es gibt auch OpenSSH für Windows, allerdings scheint mir die Installation und Konfiguration nicht mehr ganz zeitgemäß. Sofern man nicht kommerziell arbeitet, ist der  Bitvise SSH-Server kostenlos und, meiner Meinung nach, der Favorit. Als Download empfehle und verwende ich den Bitvise SSH Server installer (aktuell: Version 5.58), die Installation erfolgt automatisch und ist denkbar einfach.

Nach der Installation kann man mit dem „Bitvise SSH Control Panel“, zu finden unter „C:Program FilesBitvise SSH ServerBssCtrl.exe“, die Konfiguration einrichten:

Man sollte darauf achten, dass der Server gestartet ist, wenn nicht kann man das über „Start Server“ nachholen…

Jeder Benutzer, der Zugang auf den Server erhalten soll, muss einen lokalen System-Account besitzen. Das geschieht z.B. unter Windows 7 mit Start > Systemsteuerung > Benutzerkonten > Benutzerkonten > Hinzufügen:

Mehr ist an dieser Stelle erst einmal nicht zu tun. Der automatisierte Zugang der Clients wird in den folgenden Abschnitten beschrieben.

Hinweis Windows 8:

Unter Windows 8 gibt es neben einem lokalen Account noch einen sog. „Microsoft-Account“ (Windows-Live ID). Der „Microsoft-Account“ ist ein Internet-Account und ermöglicht den Zugriff auf  Internet Dienste von Microsoft (Skydrive etc.), sowie auf Social-Netzwerk-Dienste, wie Facebook etc. Um den Bitvise SSH Server einzurichten, muss man zudem über einen sog. lokalen Account verfügen!

Dazu bewegt man die Maus auf die rechte, obere Ecke des Bildschirms und klickt „Einstellungen“ an:

Danach wählt man rechts unten „PC Einstellungen ändern“. Danach unter „PC-Einstellungen“ > „Benutzer“ > „Ihr Konto“ den Button „Zu einem lokalen Konto wechseln“ anklicken.

Richtet Euch ein lokales Konto ein und meldet Euch mit diesem Konto an, danach ist die Installation des Bitvise SSH-Server möglich! 

 

Client

Damit ein Client bzw. Benutzer sich auf dem Server einloggen kann, muss für ihn ein Account auf dem Server existieren! Ansonsten ist das Prinzip ist immer das Gleiche: Schlüsselpaar (Private- und Public-Key) erzeugen, Public-Key auf Server übertragen, Client den Private-Key mitteilen, auf Server einloggen.

 

Linux

Auch auf dem Linux-Client sollte man OpenSSH installieren und als Server einrichten, sofern man der Client zum Server wird und man sich auf dort remote einloggen will.

Das Schlüsselpaar lässt sich einfach durch folgenden Befehl erzeugen:

ssh-keygen -t rsa

 

Mit diesem Befehl wurde für den aktuellen Benutzer im Verzeichnis „~/.ssh“ das Schlüsselpaar erzeugt:

• Private-Key: „id_rsa“
• Public-Key: „id_rsa.pub“

Der Public-Key muss dem SSH-Server bekannt gemacht werden. Das geschieht einfach durch Kopieren der Datei „id_rsa.pub“ auf den Server.

Auf einem Linux– bzw. OpenSSH-Server kann man glücklicherweise den Befehl „ssh-copy-id“ verwenden, der nicht nur das Kopieren des Public-Key übernimmt, sondern auch die Konfiguration auf dem Server. Auf dem Linux-Client also folgenden Befehl ausführen:

ssh-copy-id -i ~/.ssh/id_rsa.pub User@SSH-Server

 

 

Dann wird auf dem Linux– bzw. OpenSSH-Server unter dem entsprechenden User im Verzeichnis „~/.ssh“ eine Datei „authorized_keys“ mit dem Public-Key des Users angelegt bzw. um diesen erweitert.

Sollte das Programm „ssh-copy-id“ fehlen, kann man sich mit folgendem Befehl helfen:

cat ~/.ssh/id_rsa.pub | ssh user@machine "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

Auf einem Windows-Bitvise-SSH-Server funktioniert weder „ssh-copy-id“, noch der Workaround, da er eine Windows-Shell verwendet, die Linux-Shell Befehle nicht erkennt. Es ist deshalb notwendig die Public-Key-Datei manuell auf den Server zu transferieren und auf diesem zu importieren.

Meine Vorgehensweise:

1. Temporäres Verzeichnis auf Windows-Server anlegen (z.B. „C:loeschen“)
2. Public-Key („~/.ssh/id_rsa.pub“) in temporäres Windows-Verzeichnis kopieren
   
3. Public-Key in Bitvise-SSH-Server (im Beispiel OS: „Windows8“, DNS: „vostro“) importieren 
   
   
   
   
   
   
4. Danach kann man sich per SSH, ohne Passwort-Abfrage, einloggen. Als Shell dient „CMD.EXE“ auf Windows:
   

 

Windows

Auf Windows-SSH-Clients verwende ich das altbewährte Putty, samt seiner Tools (PuttyGEN etc.). Man kann sich das Komplettpaket für Windows (außer PuttyTel) direkt von der Putty Download Page herunterladen, aktuell: putty-0.62-installer.exe.

Vorgehensweise:

1. Auf dem Windows-Client einloggen, von dem aus man sich zukünftig per SSH auf einem SSH-Server einloggen will
2. PuttyGEN starten (puttygen.exe)
   
3. Schlüsselpaar mit dem „Generate“ Button erzeugen, die Maus solange bewegen, bis die Erstellung des Schlüsselpaares fertig ist. Darauf achten, dass als Schlüsseltyp „SSH2 RSA“ selektiert ist:
   
   Nach der Generierung kann man das Schlüsselpaar noch mit einem Kommentar versehen und evtl. ein Passwort vergeben.

   Hinweis: Wenn man ein Passwort vergibt, dann wird dieses auch bei jedem SSH-Login abgefragt! Will man das umgehen, kann man den Pageant (Putty authentication agent) verwenden (pageant.exe), der ebenfalls installiert ist. Es handelt sich hier um ein Hintergrundprogramm, bei dem man das Passwort für den Private-Key eingibt und  danach bei jedem Login, von der Passwort-Abfrage der Keys verschont wird.

   

4. Speichern der Keys mit „Save public key“, z.B. als „id_rsa.pubkey“ und „Save private key“, z.B. als „id_rsa.ppk“.
5. Verteilen des Public-Keys auf den/die SSH-Server.
   1. Für einen Linux– bzw. OpenSSH-Server kann man den Public-Key direkt aus dem PuttyGEN Fenster kopieren und in die Datei  „~/.ssh/authorized_keys“ auf dem SSH-Server einfügen. Alternativ kann die Datei „id_rsa.pubkey“ auf den SSH-Server kopieren, z.B. nach „/tmp/id_rsa.pubkey“. Hierfür kann man putty, pscp.exe (im Putty Verzeichnis), WinSCP, FileZilla etc. verwenden. Eine direkte Verwendung der Datei war bei mir erst möglich, nachdem ich an den Anfang der Datei „ssh-rsa“ eingefügt und den comment am Ende angefügt habe.
      vorher:
      
      nachher:
      
      Danach kann man auf dem Server die Datei direkt an die Datei „~/.ssh/authorized_keys“ des betreffenden Users anhängen, z.B. mit „cat /tmp/id_rsa.pubkey >> ~/.ssh/authorized_keys“:
      
      Hinweis: Falls die Datei „authorized_keys“ noch nicht existiert, kann man sie mit „touch authorized_keys && chmod 600 authorized_keys“ anlegen.
   2. Bei Windows-Bitvise-SSH-Server siehe oben.
6. Putty starten (putty.exe)
7. Session zum SSH-Server anlegen und speichern:
   
8. Session konfigurieren
   1. Category > Connection > Data, optional hier den Usernamen eingeben, mit dem man sich einloggen will:
      
   2. Category > Connection > SSH > Auth, hier den Private Key selektieren:
      
   3. Auf Session zurückgehen und Einstellungen mit „Save“ speichern:
      
9. Mit „Open“ die gespeicherte Session öffen. Wenn bei Einrichten des Schlüsselpaares eine Passwort angegeben wurde, wird man nach diesem gefragt. Um das zu vermeiden, kann man, wie bereits erwähnt, den Pageant (Putty authentication agent) verwenden (pageant.exe).
   
   Mit einem Rechtsklick > Add Keys kann man das Passwort für den Private-Key eingeben und wird bei jedem Login auf dem SSH-Server von einer weiteren Passwortabfrage verschont.
   

 

Fazit

Ich gebe zu, dieser Artikel existiert wahrscheinlich bereits zig-tausendmal im Web, und wahrscheinlich habe ich das Ganze auch schon zigmal durchgeführt – allerdings habe ich mir immer wieder die Infos mühsam zusammengesucht. Grund genug also, das Ganze in einer Post zusammenzufassen.

Die Konfiguration lässt sich sowohl auf  Windows, als auch auf Linux relativ einfach erledigen und spart dem Heimnetz-Admin-Alltag viel Zeit, die man mit unnötigen Logins verschwendet. Zudem wird das Ganze im Gegensatz zu Telnet oder FTP verschlüsselt – man weiß ja nie, ob sich jemand ins WLAN gehackt und einen Sniffer am Laufen hat. Ohne paranoid wirken zu wollen, aber offensichtlich schein es relativ einfach möglich zu sein (siehe Google: „wlan hacken“), auf ein fremdes WLAN zuzugreifen.

Aber das Tüpfelchen auf dem „i“ sind die Möglichkeiten, die man mit einer SSH-Umgebung machen kann. Da wäre das SSH/OpenSSH/PortForwarding, speziell das X11-Forwarding und andere Features, die mit SSH ermöglicht werden, siehe  25 Best SSH Commands / Tricks.

Links:

Ubuntu Wiki: SSH

OpenSSH

PuTTY Download Page

Bitvise SSH Server installer

25 Best SSH Commands / Tricks

 

 

Windows7 Freigaben ohne Active Directory

Da denkt man für sich, man hat den Stein der Weisen gefunden, um so ein scheinbar triviales Problem, wie die volle (Schreib-/Lese-) Freigabe unter Windows für alle Heimgruppen-Benutzer, gefunden zu haben und stellt im Nachhinein fest, dass man sich mal wieder zu früh gefreut hat – grmpf – 😦

Was ich im untenstehenden Artikel beschreibe, ist nichts anderes als eine lesende Freigabe für „Jeder“ zu setzen.

Will man einen Schreib-/Lese-Zugriff automatisch über eine Heimnetzgruppe bewerkstelligen, dann muss man das Laufwerk oder Verzeichnis als Bibliothek kennzeichnen. Zumindest verstehe ich das so. Ohne Bibliotheken scheint das nur mit expliziter Authentifizierung bzw. über LDAP, ADS oder Samba möglich zu sein. Oder man geht den Umweg über die Konsole (cmd.com) und trennt das Laufwerk über „net use … /DELETE“ und bindet es anschließend über „net use … /USER:…“ wieder ein.

Für alle, die sich keinen Windows Server leisten können, sich mit Linux (Ubuntu) auskennen und trotzdem in den Genuß einer zentrale User- und Dateiverwaltung für Windows kommen wollen, sei auf folgenden Artikel verwiesen: „Samba Server PDC„.

Ursprünglicher Artikel:

Ich habe mich bisher nicht wirklich mit dem Freigabemechanismus von Windows7 und den Heimnetzgruppen beschäftigt. Klar habe eine solche eingerichtet und mit Bibliotheken etc. gearbeitet, aber womit ich bisher immer Probleme hatte, war die Tatsache, das Freigaben auf anderen Computern der Heimnetzgruppe nicht sichtbar bzw. gesperrt waren. Ich habe dann mit „net use … /DELETE“ gearbeitet und mit Authentifizierung neu verbunden, dachte mir aber, das kann es nicht sein.

Ich denke, jetzt habe ich die Lösung gefunden: eine einfache Einstellung in der Netzwerkfreigabe:

1) Start > Systemsteuerung

2) „Netzwerk und Internet“ > „Heimnetzgruppen- und Freigabeoptionen auswählen“

3) Nach unten scrollen und „Erweiterte Freigabeeinstellungen ändern…“

4) „Privat oder Arbeitsplatz wählen“

5) Ganz nach unten scrollen und unter „Heimnetzgruppen-Verbindungen“ den Punkt „Benutzerkonten und Kennwörter zum Herstellen von Verbindungen mit anderen Computern verwenden“

6) „Änderungen speichern“ (als Administrator)

Danach sollte der Zugriff auf Freigaben dieses Computers ohne Probleme möglich sein. Wichtig ist, dass auf den anderen Computern der Heimnetzgruppe, der gleiche Account existiert. Wie bereits erwähnt, es geht um Heimnetzgruppen, nicht um ADS Accounts!

 

Cygwin Bash aus ausgewähltem Explorer Verzeichnis starten

Original: http://snippets.dzone.com/posts/show/10227

Want to launch a bash shell in any directory using the Windows Explorer context menu? This is how I did it, tweaking the basic method described here. This should work even for paths that have spaces or for UNC paths.

1. Edit Registry
– Start regedit.exe.
– Add these key/values:
HKEY_CLASSES_ROOTDirectoryshellBashHere=bash here
HKEY_CLASSES_ROOTDirectoryshellBashHerecommand=

cmd.exe /c C:cygwincygwin.bat "%1"

Note the quotation marks around „%1“.
Please adjust the path to cygwin.bat if necessary.

2. Edit cygwin.bat in c:/cygwin

This batch starts the bash shell with the last command line „bash…“.
Insert

set BASHHERE=%1

the line before.

This Environment variable now contains the complete path of the opened
folder and is available in the bash shell (echo $BASHHERE).

3. Edit profile

Make $BASHHERE the current directory by adding the following line to
/etc/profile or ~/.profile. (I’d replace your line cd „${HOME}“ with the following):

  if [ "$BASHHERE" != "" ]; then
    cd "$(cygpath -u "$(echo $BASHHERE | tr -d "42")")"
  else
    cd "${HOME}"
  fi

The „tr -d“ deletes enclosing quotes, which cygpath can’t deal with for some reason when embedded in $BASHHERE. Maybe there’s a simpler way, but this way worked for me.

(For UNC paths, cmd.exe complains when you launch cygwin.bat, but it dutifully passes on the argument.)

 

Command Prompt aus ausgewähltem Explorer Verzeichnis starten

Original: Petri IT KB

1. Navigate in your Registry to

   HKEY_LOCAL_MACHINE/Software/Classes/Folder/Shell

   and create a key called „Command Prompt“ without the quotes.

2. Set the default string to whatever text you want to appear in the right-click menu.
3. Create a new key within your newly created command prompt named „command,“ and set the default string to

   cmd.exe /k pushd %1

   You may need to add %SystemRoot%system32 before the cmd.exe if the executable can’t be found.

4. The changes should take place immediately. Right click a folder and your new menu item should appear.

 

Windows Netzwerk: net use mit Systemfehler 1219

Der Systemfehler 1219 tritt auf, wenn ein Benutzer versucht unter einem anderen Benutzernamen eine zweite Sitzung zu einem Server aufzubauen.

Mit dem Befehl „net use“ sieht man die bestehenden Netzwerkverbindungen und durch den Parameter „/DELETE“ kann man dediziert Verbindungen löschen. Man kann aber auch eine zweite Verbindung aufbauen, indem man anstelle des DNS Namens die IP-Adresse verwendet. Diese kann man leicht mit einem Ping auf den DNS Namen ermitteln.

Beispiel:

C:> net use X: \myservertest /user:domarbeiter

C:> net use Y: \10.0.0.2test /user:domadministrator

Nun haben wir 2 Laufwerksbuchstaben mit dem gleichen Share verbunden 🙂

(Hinweis: Tipp entnommen aus http://www.nwlab.net/art/system-error-1219/systemfehler-1219.html)