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:

  1. 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

  1. Setzt den HEAD auf den genannten Branch
  2. Kopiert den Objekt-Tree, der durch den dortigen Commit referenziert wird in die Working Area.

Was macht Reset

git reset –hard HEAD

  1. 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 :-))
  2. 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:

  1. Bereinigen der merkierten Stellen „>>>>“ „<<<<„
  2. Git add file
  3. 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!