HTTP URL Address Encoding in Java

Motivation

Bei der Erstellung einer URL, können bestimmte Zeichen zu Problemen führen („Illegal character at position…“). Das liegt daran, dass man in einer URL nicht alle Zeichen des ASCII-Zeichensatzes direkt übergeben darf, siehe auch: https://de.wikipedia.org/wiki/URL-Encoding:

Bei einem HTTP-Zugriff beispielsweise:

Weitere Zeichen haben spezifische Bedeutungen im Dokumentenpfad. Folgende Zeichen gelten als reserviert:

  • : / ? # [ ] @ $ & ' ( ) * + , ; =

Folgende Zeichen sind nicht reserviert, besitzen also in einer URL keine vorgegebene Bedeutung:

  • Buchstaben: A-Z, a-z
  • Ziffern: 0-9
  • - . _ ~

Relevante ASCII-Zeichen in Prozentdarstellung

! # $ % & ( ) * + , / : ; = ? @ [ \ ] { | }
%20 %21 %22 %23 %24 %25 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5C %5D %7B %7C %7D

 

Lösung

Die folgende Lösung habe ich entnommen aus: http://stackoverflow.com/questions/724043/http-url-address-encoding-in-java.

In der Methode  isUnsafe kann man die Sonderzeichen in  return " %$&+,/:;=?@<>#%".indexOf(ch) >= 0;  erweitern, z.B. um „[]{}“ etc.

 

git client für GitLab-CE auf Windows einrichten

Motivation

Man möchte einem bestehenden GitLab-CE Benutzer auf einem Windows-Rechner ermöglichen, sich auf GitLab zu identifizieren und mit Projekten zu arbeiten (klonen, etc.).

Vorgehensweise

  1. Man benötigt den MSI-Installer von Putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
    Damit werden auch Pagent, PuTTy und PuTTYgen installiert
  2. Download eines git-Clients für Windows, z.B.: https://git-for-windows.github.io/
  3. In das Home-Verzeichnis des Benutzers wechseln und das Unterverzeichnis .ssh anlegen
  4. PuTTY Key Generator starten: Start > PuTTY > PuTTYgen
  5. Den Generate-Knopf drücken und die Maus bewegen, bis der Balken vervollständigt ist
  6. PuTTYs privaten Schlüssel speichern, z.B.  C:\Users\<Username>\.ssh\putty_private_key.ppk
  7. PUTTYs öffentlichen Schlüssel konvertieren: Menü > Conversions > Exort OpenSSH key
    unter z.B. C:\Users\<Username>\.ssh\id_rsa
  8. Den öffentlichen Schlüssel aus dem Fenster komplett in die Zwischenablage kopieren (Strg-C):
  9. In GitLab-CE einloggen und die Benutzer-Einstellungen aufrufen:
  10. „SSH Keys“ in der oberen Leiste wählen
  11. Den öffentlichen Schlüssel kopieren (Strg-V) > Tab > Add key:
  12. „SSH Keys“ in der oberen Leiste wählen
  13. git-Client für Windows aufrufen Start > Git > Git Bash:
  14. In lokales Git-Verzeichnis wechseln oder anlegen, z.B.:
  15. Einmalig die globalen Git-Konstanten setzen:
  16. Projekt aus GitLab-CE klonen:

    Hinweis: „The authenticity of host ‚ubuntus64 (192.168.0.4)‘ can’t be established.“ wird nur beim ersten mal abgefragt !

Kleiner Tipp: Wenn man den Key aus 8. auf das GitLab-CE-Unix-System in die Datei ~/.ssh/authorized_keys seines Benutzers kopiert bzw. anhängt und auf dem Windows-System den Pagent startet, den Putty Key hinzufügt und anschließend in den Putty-Settings unter Connection > SSH > Auth auswählt, kann man sich ohne Passwort-Abfrage auf dem Unix-System einloggen (siehe auch: Using public keys for SSH authentication).

Links:

Download GitLab-CE

Windows git-Client

TortoiseGit

 

Git: Kurzrezept um Git-Repositories über ein Filesystem zu sharen

1) Lokales git-Projekt (Arbeitskopie) anlegen: mkdir <Projekt>
Beispiel Windows Host A: mkdir E:\juergen\workspace\testprojekt

– cd <Projekt>
Beispiel Windows Host A: cd E:\juergen\workspace\testprojekt

– In git als Arbeitsverzeichnis (working directory) anlegen: git init
Beispiel Windows Host A: Git Bash im aktuellen Verzeichnis (E:\juergen\workspace\testprojekt) öffnen
Beispiel Windows Host A/Git Bash: git init

– Files erstellen, z.B.: README.txt

– File(s) hinzufügen, git add <Datei>
Beispiel Windows Host A/Git Bash: git add README.txt

– git commit -a -m ‚<Kommentar>‘
Beispiel Windows Host A/Git Bash: git -a -m 'initial revision'

2) Repository anlegen
– mkdir <Repository>
Beispiel Windows Host A: mkdir E:\juergen\owncloud\jkh\40_DEV\01_git\jkh  ==> Repository = jkh

– cd <Repository>
Beispiel Windows Host A: cd E:\juergen\owncloud\jkh\40_DEV\01_git\jkh

– mkdir <Projekt>.git
Hinweis: Für Repositories hat sich der Suffix .git eingebürgert. Das wird auch bei manchen Tools, z.B. Eclipse EGit, vorausgesetzt.
Beispiel Windows Host A: mkdir testprojekt.git  ==> Projekt = testprojekt

– cd <Projekt>
Beispiel Windows Host A: cd testprojekt.git

– In git als Repository anlegen: git –bare init
Beispiel Windows Host A: Git Bash im aktuellen Verzeichnis (E:\juergen\owncloud\jkh\40_DEV\01_git\jkh\testprojekt.git) öffnen
Beispiel Windows Host A/Git Bash: git --bare init

3) Lokales git-Projekt zum Repository pushen
– Verlinken lokal->Rep: git remote add origin file:///<Repository>/<Projekt>
Beispiel Windows Host A: mkdir E:\juergen\workspace\testprojekt
Beispiel Windows Host A/Git Bash: git remote add origin file:///e/juergen/owncloud/jkh/40_DEV/01_git/jkh/testprojekt
Hinweis: Netzwerklaufwerke auf Windows, z.B. „\\rechner123\Share1“ als Repository benutzen: git remote add origin //rechner123/Share1

– Pushen lokal->Rep: git push origin master
Beispiel Windows Host A/Git Bash: git push origin master
Hinweis: Mit dem Befehl git remote remove origin  kann man die Aktion wieder rückgängig machen.

4) Repository-Projekt lokal (neu) vom Server clonen und ändern:
– Wechseln in das Verzeichnis, in welches das Repository-Projekt kopiert bzw. gecloned werden soll
Beispiel Windows Host A: cd C:\juergen\workspace

– git clone file:///<Repository>/<Projekt>
Beispiel Windows Host A: Git Bash im aktuellen Verzeichnis (C:\juergen\workspace) öffnen
Beispiel Windows Host A/Git Bash (Rep auf lokalem Filesystem): git clone file:///e/juergen/owncloud/jkh/40_DEV/01_git/jkh/testprojekt
Beispiel Windows Host A/Git Bash (Rep auf remote Filesystem): git clone file:////remote/Share1

– cd <Projekt>
Beispiel Windows Host A: cd C:\juergen\workspace\testprojekt

– Änderungen durchführen

– git commit -a -m ‚<Kommentar>‘
Beispiel Windows Host A/Git Bash: git commit -a -m 'changed and added something'

– Pushen (Update Rep: lokal->Rep): git push
Beispiel Windows Host A/Git Bash: git push

– Pullen (Update Arbeitskopie: Rep->lokal): git pull
Beispiel Windows Host A/Git Bash: git pull

markiert

Homebrew – The missing packet manager for OSX

Homebrew ist ein Paket-Manager für OSX, mit dem man in einfacher Weise „fehlende“ Programme, wie z.B. wget, installieren kann. Installation:

 

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:

git config --global user.name "Your Name"

git config --global user.email your@email.com

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:

 

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

bzw.

git commit m Kommentar

 

Änderungen rückgängig machen

 

Task Befehl

Workspace
(W)

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

 

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:

 

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“:

 

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

 

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:

 

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

 

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:

 

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“:

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

%d Bloggern gefällt das: