Home » Beitrag verschlagwortet mit 'GIT'

Schlagwort-Archive: 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 Commits zusammen fassen

A: Git rebase interactive starten:

git rebase --interactive HEAD~N

Dabei bezeichnet N die anzahl der jüngsten Commits auf dem current Branch. Alternativ kann die Commit ID des ältesten einzubeziehenden Commits bezeichnet werden.

B: Mittels ’s‘ (sqisd) am Zeilenanfang, im augegangenen VI editor diejenigen Commits markieren, die miteinander verschmolzen werden sollen. Ich glaube einen der Commits muss man auf der Anweisung ‚pick‘ belassen, damit dort hinein gemixt wird.

C: Speichern (in VI: wq!)

D: Eine einzige zusammenfassende Commit-Meldung schreiben. Mit ‚#‘ auskommentierte Zeilen werden ignoriert. Speichern (wq!)

E: Fertig

Link: https://www.internalpointers.com/post/squash-commits-into-one-git

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.

==> Wie kann ich Dateien mit dem Editor „vi“ editieren?

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 – Cheat Sheet / Git – Wichtigste Kommandos

https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet

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!

Git Workflow

Ressourcen

Wichtigstes: https://rogerdudler.github.io/git-guide/index.de.html

Die Doku: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Tutorial mit typischem WorkFlow: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners

Schnelle Einführung in Git (auf Deutsch): http://www.andreas-schrade.de/2015/03/11/git-kompakte-einfuehrung/

Eigenes Dokument:

GIT / GitHub

A) Remote- und Local-Repository erstellen

  1. Repository erstellen
    a) Lokal
    git init
    b) Auf GitHub
    –> Irgend so ein „Create Repository“-Button.
  2. Repository einchecken
  3. Ganzes Repository vom Remote-Repository neu als lokal bewirtschaftete Kopie auschecken:
    git clone <Pfad zum Remote-Repository>
    Nicht zu verwechseln: git pull (Beziehen von neuerungen im Remote-Repo)

B) Typischer Enwickler-Zyklus (entnommen von da.)

  1. Für die geplanten Änderungen einen Feature-Branch erstellen und dort hin wechseln:
    Zuerst noch letzte Änderungen holen:
    git pull

    git checkout -b iss53
  2. Code-Änderungen ins lokale Repository committen:
    git commit -a -m 'added a new footer [issue 53]'

    (Dies ist die Abkürzung für git add … gefolgt von git commit …)

3. Feature-Branch mit dem Master mergen

Auf den Master wechseln: git checkout master

Letzte Änderungen des Masters holen: git pull

Mergen: git merge iss53

Ich denke das muss gemacht werden, um die Gefahr zu verkleinern, daass während dem folgenden Schritt – merge auf dem Remote-Repository – Merge-Konflikte auftauchen, die dann dort gelöst werden müssen.

Konflikte lösen: Siehe z.B. hier (suche nach Kapitel „Basic Merge Conflicts“)

 

3. Änderungen/Feature-Branch ins Remote-Repository schicken und dort vorschlagen:

git push origin iss53

Auf GitHub ist der neue Branch nun sichtbar unter „Branches“. Es wird dort dann auch ein Button „Create pull request“ angeboten.

4. Pull-Request erstellen

Button: „Create pull request“

Nach Ausfüllen und Abschicken des Requests ist er sichtbar unter Button „Pull requests“.

5. Pull-Request approven und mergen:

Via Button „Merge“ wird der Feature-Branch auf den Master gemerget.

 

Feature-Branch von jemand anderm aus dem Remote-Repo holen

 

  1. Anzeigen der verfügbaren Branches im Local- und Remote-Repository
    git branch -v -a
  2. Von Repository Master und Branches
    git fetch origin
    Dann hat man alle Branches des Remote-Repos auch lokal und kann z.B. mit dem Mergen beginnen. Anleitung dazu ist hier.

Lokales Repo: Unterteilung

a) Working Directory:
Dateien auf dem lokalen Rechner, die durch Programmierer verändert werden.
Move von a -> b via: git add
–> Neuer Status der hinzugefügten Dateien: Staged


b) Index / Staging Area: 
Ist eine Datei, in der die Aenderungen verzeichnet werden.
Anzeigen, was im Index vorliegt/für commit bereit ist: git status
Move von b -> c via: git commit -m <Aenderungsbeschrieb>

c) Head:
(.git-Verzeichnis) Lokale VCS-Datenbank, mit den der Aenderungshistorie drin (alle Commits) –> 1. .git-Verzeichnis pro Repository
Anzeigen, was im Head ist: git log

Willkürliches Kommando-Listing

  1. Ausstehende Commits anzeigen (was noch nicht in der Staging-Area und nicht im Feature-Brach ist):
    git status
  2. Status des HEAD aschauen:
    git log
  3. Branch erstellen
    git checkout -b <Branchname>
  4. Branch liefern
    git push -u origin <Branchname>
  5. Branch mit Master mergen lokal
    1) zum Master wechseln: git checkout master
    2) Master aktualisieren: git pull
    3) Merge vom Branch: git merge <Branchname>
  6. Zwischen Branches und/oder Master wechseln
    git checkout <Branchname>  respektive git checkout master
  7. Branches anzeigen:
    git branch
  8. Merge bei Konflikten:
    Siehe z.B. hier (suche nach Kapitel „Basic Merge Conflicts“)
  9. Update (Beziehen von Neuerungen aus dem Remote-Repository):
    git pull