Home » Software Repository » GIT
Archiv der Kategorie: GIT
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 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!