Git:Herunterladen (Pull) und Hochladen (Push) aus der Shell mit http/https

Dieses Thema ist noch nicht vollständig! Es wird noch daran gearbeitet!

Ist mein persönlicher Merkzettel wie was geht

Herunterladen vom Repository

Dazu brauchen wir die Web-Adresse in der Regel zu finden auf der Webseite des Git-Repository:

In der Shell wechseln wir in den Ordner in dem wir den Inhalt als neuen Unterordner herunterladen wollen.
Der Befehl git clone wird immer ein neues Unterverzeichnis mit dem Namen des Repositorys erstellen (ohne das .git am Ende).

git clone http://git.znil.net/mediawiki/IPInfo.git

erstellt also einen neuen Unterordner IPInfo im aktuellen Verzeichnis.

Änderungen herunterladen

Im entfernten Repository gibt es Änderungen die wir nun auch lokal haben wollen?
In das Verzeichnis wechseln, also in diesem Beispiel in den Ordner IPInfo und folgenden Befehl eingeben:

git pull

Dabei versucht Git ggf. die Änderungen vom Web-Repository mit den lokalen Änderungen zusammen zu führen.
Wollen wir alles lokale Ignorieren und einfach alles mit der Version aus dem Web-Repository ersetzen so nutzen wir folgende Befehle:

git fetch origin
git reset --hard origin/master

Änderungen hochladen Teil 1: Nein!

Nein nein, nicht so schnell.
Bei Git wird das nicht ständig auf den Server hochgeladen.
Siehe nächsten Punkt:

Hinzufügen (Add) und Bestätigen (Commit)

Wir können lokal arbeiten und dabei immer wieder Zwischenstände abspeichern. (= zum Index hinzufügen)
Dazu müssen wir ihm aber jedesmal sagen welche Datei er dabei beachten soll:

git add README.md

Wollen wir alle geänderten Dateien hinzufügen nutzen wir

git add *

Dabei werden aber nur Dateien im aktuellen Verzeichnis hinzugefügt. Wenn auch alle Unterverzeichnisse berücksichtigt werden sollen (Rekursiv) nehmen wir den . statt *:

git add .

Damit sind die Änderungen aber noch nicht zwischengespeichert. Das geschieht mit dem folgen Befehl:

git commit -m "Beschreibung"

Wir sollten also gleich eine kleine Beschreibung dazu geben was wir geändert haben. Das ist der Text der dann auch später auf der Repository-Webseite hinter den jeweiligen Dateien zu sehen ist:

Jetzt sind die Änderungen lokal abgespeichert - diesen Stand können wir nun "hochladen"

Änderungen hochladen Teil 2: Push!

Das geht nun (beim ersten mal) mit

git push origin master

Dabei wird er euch dann in der Regel nach dem Benutzernamen und dem Passwort fragen:

Zähle Objekte: 3, Fertig.
Delta compression using up to 2 threads.
Komprimiere Objekte: 100% (3/3), Fertig.
Schreibe Objekte: 100% (3/3), 275 bytes | 0 bytes/s, Fertig.
Total 3 (delta 2), reused 0 (delta 0)
Username for 'https://git.znil.net': Benutzername
Password for 'https://Benutzername@git.znil.net': Passwort
To http://git.znil.net/mediawiki/IPInfo.git
   5e6a354..8f648d2  master -> master
Branch master konfiguriert zum Folgen von Remote-Branch master von origin.

Nachdem Ihr einmal hochgeladen habt reicht später auch einfach ein

git push

Muss ich jetzt jedesmal den Benutzernamen und das Passwort eingeben?

Ja. Wenn man dazu zu faul ist kann man aber auch abspeichern lassen.
Dazu gebt Ihr folgenden Befehl ein:

git config credential.helper store

und danach macht Ihr erst den Push. Bei diesem wird er wieder nach dem Benutzernamen und dem Passwort fragen - diesmal wird er es aber speichern.
Danach wird er nicht mehr danach fragen.
Er legt dazu in eurem HOME Verzeichnis eine Datei mit dem Namen

.git-credentials

an. In dieser speichert er den Benutzernamen und das Passwort in Klartext!

Je nach verwendeter Git-Software gibt es auch andere Methoden, z.B. einen Schlüssel pro Repository. Diese werden dann in der Regel der URL voran gestellt - genaueres steht in der Anleitung eures Git-Servers.

Änderungen zum letzten Commit Rückgängig machen

Ihr habt - nachdem Ihr einen Commit durchgeführt habt - was verfriemelt und wollt auf den letzten Stand zurück?

 git checkout -- Dateiname

Dreht euch die angegebene Datei zurück.

Mehrere Commit Stände zurückspringen

Wenn du auf einen früheren Stand zurückspringen willst suchst du dir diesen zunächst heraus:

git log

ergibt eine List wie diese:

commit 8f648d28b2d4c0dfac42f3686adabd02a9154e47
Author: root <root@znil.net>
Date:   Sat Sep 9 16:03:56 2017 +0200

    noch ein Test

commit 5e6a35476c550186895b0d729d2d7c77103c024e
Author: root <root@znil.net>
Date:   Sat Sep 9 14:15:14 2017 +0200

    nur ein Test

commit 74461f783594a34082ed9ad715c211a7c88fc052
Author: root <root@znil.net>
Date:   Sat Sep 9 14:12:01 2017 +0200

    Email ergänzt

commit 6a4e4ab5973214ff22f637b14f2fc9de57a28ee3
Author: root <root@znil.net>
Date:   Sat Sep 9 14:08:46 2017 +0200

    Namen eingefügt

commit 151063b2bec95ff9704309b745cbdbf25042a887
Author: mediawiki <mediawiki@znil.org>
Date:   Fri Sep 8 17:46:45 2017 +0200

    'README.md' ändern

commit 17f3354dd740221672dfaa566ceadc81dfb1cf8c
Author: mediawiki <mediawiki@znil.org>
Date:   Fri Sep 8 17:45:58 2017 +0200

    'README.md' ändern

commit 735f23310e076122dae4f9c7f210691faa160572
Author: mediawiki <mediawiki@znil.org>
Date:   Fri Sep 8 17:39:21 2017 +0200

    Dateien hochladen nach ''

commit 308e4dd1383e7a6d0a5918c4c06bacc7eaf5e5ca
Author: mediawiki <mediawiki@znil.org>
Date:   Fri Sep 8 17:37:35 2017 +0200

    Initial commit

Jetzt sehen wir auch wozu die Kommentare gut sind :-)
Der letzte stand steht ganz oben, der erste ganz unten. Von Oben nach Unten reisen wir also in der Zeit zurück.
Von dem Stand zu dem wir springen wollen brauchen wir die passende Nummer, das ist die die hinter dem Wort commit steht:

git reset --hard 5e6a35476c550186895b0d729d2d7c77103c024e

Dreht alles auf diesen Stand zurück - und alles dahinter wird gelöscht!

Ich will nur mal einen älteren Stand ansehen

Klar des geht auch, nur eine kleine Zeitreise.
Bevor Ihr das tut solltet Ihr den jetzigen Stand noch einmal mit Add + Commit wegschreiben! Oder diesen bewusst wegwerfen mit

Wiederum die passende Commit-Nummer ermitteln und diesen Befehl:

git checkout 17f3354dd740221672dfaa566ceadc81dfb1cf8c

springt in diesem Fall auf den Stand von Fri Sep 8 17:45:58 2017 +0200 zurück.
Jetzt könnt Ihr euch jede Datei ansehen - und zum Beispiel herauskopieren - bitte nach Außerhalb des Git-Verzeichnisses!
Bitte NICHTS ändern. Denn ändert Ihr in der Vergangenheit etwas ... und schafft euch eine alternative Realität. Das kann gewollt sein und nennt sich Branch - das wollt Ihr nur wenn Ihr wisst was das ist. Also schaut euch an wie es aussah und kopiert euch ggf. die Sachen heraus.
Dann springen wir wieder zurück in die Gegenwart:

git checkout master

springt wieder auf den letzten Stand (deshalb ja vorher Add + Commit)

Ich hätte würde gerne eine Datei auf einen älteren Stand zurücksetzen

Weiter oben hatten wir schon wie wir auf den letzten Stand zurückspringen.
Wollen wir die Datei aus einem älteren Stand holen so ermittelt mit

git log

wieder die zugehörige Nummer. Und mit

git checkout 17f3354dd740221672dfaa566ceadc81dfb1cf8c README.md

bekommt Ihr dann die Datei.

Aktuellen Stand als Release herausbringen

Der aktuelle Stand ist eine gute Version und soll als diese Veröffentlicht werden. Dann gebt nach dem Commit folgendes ein:

git tag 1.0.0 -m "Version 1.0.0"

Die 1.0.0 ersetzt Ihr mit eurer Versionsnummer.
Ihr könnt auch einen älteren Stand als Version herausbringen, dazu wieder mit git log die Nummer herausfinden und dann mit

git tag 0.9.0 -m "Version 0.9.0" 151063b2bec95ff9704309b745cbdbf25042a887

Das ist nun alles ersteinmal nur lokal. Auf dem Server bringt Ihr die Änderung das mit

git push --tags

Das läuft getrennt vom normalen Push!
Um ein Release wieder zu löschen braucht es folgenden Befehl:

git tag -d 0.0.1

Löscht die Version 0.0.1 wieder.
Damit das Release auch im Web-Repository verschwindet:

git push origin :0.0.1

also wieder unter der Angabe der Versionsnummer - Beachtet den : davor!

Windows CRLF <=> LF

Git unter Windows wandelt per Default alle LF in CRLF beim herunterladen eines Repositorys um.
Umgekehrt werden beim hochladen alle CRLF in LF umgewandelt:

warning: LF will be replaced by CRLF in usr/lib/zabbix/externalscripts/znitro.sh.
The file will have its original line endings in your working directory.

Wenn man das nicht will kann man wie folgt das für ein einzelnes Repository ausschalten:

. legt im Hauptverzeichnis eine Datei mit dem Namen

.gitattributes

an. Das geht am besten in der Git Bash mit

touch .gitattributes

Inhalt:

# Immer LF statt CRLF verwenden:
text eol=lf

Habt Ihr die Datei erst nachträglich nach dem git add . aber vor dem git commit angelegt so fürht ein

git add -u

durch.

Proxy nutzen

Mit folgenden Befehl weist man git an - global - für den Zugriff auf http/https URLs einen Proxy zu nutzen:

git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Beispiel (Nur IP + Port, keine Anmeldung):

git config --global http.proxy http://192.168.33.77:3128

Man kann aber auch einen Proxy nur für bestimmte URLs setzen. Praktisch wenn es einen internen und einen externen Git-Server gibt:

git config --global http.https://git.znil.net.proxy http://192.168.33.77:3128

nutzt den Proxy nur beim Zugriff auf den Git-Server https://git.znil.net. Man beachte das http. vor der URL und das .proxy danach.

Löschen kann man diese oder andere Konfigurationsparameter übrigens mit dem zusätzlichen Parameter

--unset

zum Beispiel

git config --global --unset http.proxy http://192.168.33.77:3128

An mehrere Repositories gleichzeitig pushen

Nach etwas suchen und probieren fand ich eine Lösung wie man bei einem

git push -u origin master

den Inhalt an zwei (oder mehr) Git-Repositories gleichzeitig pushen kann. Jedenfalls fast.
Dazu bearbeiten wir die Datei

.git\config

Diese liegt in eurem Repository-Verzeichnis und ist normalerweise versteckt:

so sieht das Original aus:

[core]
	bare = false
	repositoryformatversion = 0
	filemode = false
	symlinks = false
	ignorecase = true
	logallrefupdates = true
[remote "origin"]
	url = https://dggit/End2End/zAppMonClient.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[http]
	sslVerify = false
[branch "master"]
	remote = origin
	merge = refs/heads/master

Jetzt fügen wir einen zusätzlichen Abschnitt wie folgt ein:

[remote "znil"]
	url = https://git.znil.net/End2End/zAppMonClient.git
	fetch = +refs/heads/*:refs/remotes/origin/*

Damit kann man zusätzlich zum normalen push nun

git push -u znil master

durchführen und er pusht dann an den zusätzlichen Ort.
Das znil könnt Ihr natürlich durch einen eigenen Begriff ersetzen.
Um es einfacher zu machen fügen ich noch einen weiteren Abschnitt ein:

[alias]
	pushall = !git push -u origin master && git push -u znil master

Nun reicht ein

git pushall

und es wird immer an beide Repositories gepusht:

Der letzte Aufruf ist dann auch der Branch master dem das lokale Repository folgt. Also ggf. die Reihenfolge entsprechend setzen.

Hinweis: man kann das 2. Repository natürlich auch die entsprechenden Befehle hinzufügen. Scheinbar kam es dabei aber wohl vor das die Original URL überschrieben wurde. Mit dem Editieren der .git\conf bin ich diesem Problem einfach aus dem Weg gegangen

Hilfreiche Links

https://rogerdudler.github.io/git-guide/index.de.html
http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/de/ch02.html
An mehrere Repositories gleichzeitig pushen https://stackoverflow.com/questions/14290113/git-pushing-code-to-two-remotes
Global Config löschen https://stackoverflow.com/questions/11868447/how-can-i-remove-an-entry-in-global-configuration-with-git-config
Proxy https://gist.github.com/evantoli/f8c23a37eb3558ab8765

Kommentare

Loading comments...