Home » Software Repository
Archiv der Kategorie: Software Repository
GIT Large File Support – Grosse Files ins GitHub stellen
Git lässt Files mit wenigen MBs zu. Um grössere Files pushen zu können muss man https://git-lfs.com installieren.
Ich hatte mit diesem Tool eine Scheiss-Zeit! Habs nicht in anständiger Zeit hingekriegt ein 27MB File hoch zu laden.
Grrrrrr!!!
Meine Bemühungen waren im Rahmen von https://github.com/HPSDeveloper/NatTableExercised
Diese Seite dokumentiert den Ärger mit diesem uns zugemuteten Tool: https://github.com/git-lfs/git-lfs/issues/1581
Git Commit-Meldung ändern
Die Meldung des letzten Commits kann mit dem GIT-Ammend angepasst werden:
git commit --amend "Neue meldung, mit 'amend' erstellt"
Leider geht das nur für den letzten Commit. Will man mehrere Commits anpassen kann man das mittels dem Rebase Feature. Zur Erinnerung: Rebase operiert erstens auf dem derzeitigen Branch und einem als Parameter mitgegebenen Ziel-Branch. Vom gemeinsamen Vorfahren der beiden Branches ausgehend werden alle Commits bis zum derzeitigen Branch (als Commit-Kopie)auf den neuen Branch angefügt.
Gehen wir von dieser Ausganslage aus:
C1 -> C2 -> CA1 -> CA2 \-> CB1 -> CB2
Dann ist C2 der gemeinsame Vorfahre von CB2 und CA2. Wenn HEAD (derzeitiger Brach) auf CB2 zeigt und wir
git rebase CA2
machen, dann resultiert:
C1 -> C2 -> CA1 -> CA2 -> CB1cpy -> CB2cpy \-> CB1 -> CB2
CB1 und CB2 werden gelöscht, weil nach der Operation weder HEAD noch ein Branch auf diese Commits zeigt.
Nun zurück zu unserem Rename-Problem: Wie können wir Rebase benutzen um Commit-Meldungen zu ändern?
Ausgangslage ist:
C1 -> Cfalsch1 -> Cfalsch2
Wir stellen sicher, dass wir auf Cfalsch2 sind und setzen ab:
git rebase -i C1
Wir fügen also Kopien von Cfalsch1 und Cfalsch2 nochmals as Nachfolger von C1 ein.
Zusätzlich teilen wir GIT mittels opeion „-i“ mit, dass wir das im interaktiven Modus machen wollen.
Der Interaktive Modus erlaub uns (unter anderem) die Commit-Meldungen für die Commit-Kopien zu setzen.
Er tut das in dem er uns in einem VI editor ein batch script editieren lässt. In unserem Beispiel schlägt er folgendes Script mit zwei Kommandos vor:
pick Cfalsch1 Irgend eine falsche Commit-Meldung
pick Cfalsch2 Irgend eine andere falsche Commit-Meldung
Um die für den rebase benutzten Commit-Meldungen anzupassen müssen wir das command file wie folgt anpassen:
r Cfalsch1 Irgend eine verbesserte Commit-Meldung
r Cfalsch2 Irgend eine andere verbesserte Commit-Meldung
Haben wir fertig editiert quittieren wir das in der für VI editoren gebräuchlichen Art:
ESC gefolgt von :wq!
Sodann wird der rebase inclusive unseren Umbenennungen ausgeführt.
git rebase mit push- Ablauf
Ablauf Rebase featureA auf master:
Nur machen, wenn niemand anders auf demselben Feature-Branch FeatureA arbeitet!
git checkout master
git pull
git checkout featureA
git pull
git rebase master
git push --force-with-lease
git push ohne –force würde verweigert, weil, nach dem lokalen Rebase, der Commit-Ast unter dem lokalen Branch-Pointer „featureA“ nicht „fast forward“ auf den Zweig unter remote/FeatureA abbildbar ist.
Rebasing ins Remote-Repo zieht allen anderen, die auf demselben Branch arbeiten denselbigen unter den Füssen weg! Wenn diese Kollegen dann pushen wollen, findet der push einen Remote-Branch vor, der nur elend weit zurück liegend einen gemeinsamen Vorgänger mit der lokalen Version des Branches hat. Eine gewaltige Merge-Übung ist notwendig!
Man stelle sich folgendes Schreckens-Szenario vor:
- Ausgangslage Commit-History:
M1 -- M2 -- M3(master)
\-- F1 -- F2 -- F3(featureA)
2. Entwickler A macht Rebase mit Force push:
Situation Remote-Repo:M1 -- M2 -- M3(master) -- F1c -- F2c -- F3c(featureA)
3. Entwickler B hat weitere Änderungen an featureA gemacht:M1 -- M2 -- M3(master)
\-- F1 -- F2 -- F3 -- F4(featureA)
Möchte er diese nun pushen, dann müsste er zuerst F1 bis F3 mit F1c bis F3c mergen. Denn: Der gemeinsame Vorfahre von remote/featureA und local/featureA ist M1. Alles, was von M1 aus geht muss gemerged werden.
Schlimmer allerdings wäre es, wenn Entwickler B seine Änderung (F4) schon eingecheckt hätte, und B hätte (ohne vorherigen pull) sein featureA mit –force remote rebased. F4 ginge verloren, da kein Branch mehr darauf zeigen würde (–> Garbage Collection)!
Diesbezüglich ist –force-with-lease vorzuziehen, da dann beim Push geprüft wird, ob inzwischen remote nicht weitere Commits auf dem Branch angelegt worden sind.
Git Verstehen 2
GIT Areas
Git besteht aus den 4 Areas:
- Git Repo (.git Verzeichnis)
- Index (=Staging Area)
- Working Area (WA) (Das durch Git überwachte lokale File Subsystem)
- Stash
Was Checkout macht
git checkout mybranch
- Setzt den HEAD auf den genannten Branch
- Kopiert den Objekt-Tree, der durch den dortigen Commit referenziert wird in die Working Area.
Was macht Reset
git reset –hard HEAD
- Setzt den derzeitigen Branch auf den genannten Branch/Commit (hier HEAD)
(HEAD ist der Spezialfall: Da wird kein Branch(-Pointer) verschoben, das ja „derzeitiger Branch“ die Bedeutung von HEAD ist :-)) - Kopiert den Objektbaum unter dem geanannten Branch/Commit in den Index (Option: –mixed) und die WA (–hard). Bei –soft wird nicht kopiert.
Git reset –hard branchX
Copies the new HEAD from the repo to the index and WA
git reset –mixed branchX
//(Default) … to the index only (not WA)
git reset –soft branchX
Only repo affected (No overwriting of WA or index)
Spezialfall:
git reset –hard origin/branchA
Dies setzt den derzeitigen Branch auf den Branch „branchA“ des „Master“-Repos (=origin).
Das macht dann Sinn, wenn man die lokalen Änderungen (sowohl in der WA (weil –hard) als auch im Index und dem lokalen Repository auf den Stand des Remote-Branches stellen möchte. Dazu muss zuerst sinnvollerweise ein git fetch origin gemacht werden. Das ganze macht nur Sinn, wenn wir lokal auf demselben Branch „branchA“ sind, sonst gibt’s Chaos!
Git Rename
git rm file
Remove file from index and WA //interaktiv warning
git rm –cached file
Only delete from index
git mv filea fileb
Renames a file in the WA and the index
//Same effect as renaming it in the WA and then adding it to the index. (Git detects the renaming character like this too.)
Unstage
Ganzen Index zurücksetzen:
git reset –mixed HEAD
//Alles in Index (nicht WA, da nicht –hard) wird mit dem Current Branch (HEAD) über schrieben.
Einzelnes File im Index zurücksetzen:
git reset HEAD fileA
// 1. Current Branch wird auf HEAD gesetzt (ist er ja sowieso :-))
// 2. Kopiert HEAD in den index (default von reset ist –mixed)
Zurücksetzen von File in WA:Git reset –hard HEAD file //Funktioniert nicht „Cannot do hard reset with paths“
Stattdessen:
git checkout HEAD file
Achtung: Git checkout mit Pfad kann überschreibt (File in) WA! Mit Pfad ist Checkout ein gefährliches Kommando! Checkout ohne Pfad überschreibt nie.
Stash
git stash –include-untracked
//not default!!
//1. saves away differenced between WA or Index and Repo
//2. checks out the current commit. –> WA=Index=HEAD of Repo
git stash list
git stash apply
//default: applies most recent stash
//Bringt Differences zu WA und zu Index zurück.
git stash clear
Git Merge Conflicts:
Git Merge wird bemacht mit:
git merge otherBranch intoBranch
Bei Merge-Konflikten
- … bleibt git im Merge-Modus. Dies ist an den MERGE* filte im .git directory zu erkennen
- Merge kann abgebrochen werden mit git merge –abort
Merge Konflikte lösen mit:
- Bereinigen der merkierten Stellen „>>>>“ „<<<<„
- Git add file
- Git commit
Teileweise Prozessieren von Files
git add –patch fileA
// Will open interactive view to select which changes actually to stage and which not
–patch gibt’s sinngemäss auch für checkout, stash, reset,
Newer Commands
Git switch und restore sind Commando-Subsets von checkout.
git checkout: Move Head to a branch/commit && copy HEAD Tree to WA
git switch: Move Head to a branch/commit
git restore: copy HEAD Tree to WA
GIT verstehen 1
Git Rebase
Wichtig um ‚Rebase‘ zu verstehen ist einmal mehr:
Der GIT Version-Tree ist nicht auf Branches aufgebaut!
Branches sind dumme Pointer!