GIT
Wie können z.B. zwei Commits, die bereits gepusht und publiziert wurden wieder rückgängig gemacht werden?
Was passiert dabei technisch gesehen?
git revert HEAD~2..HEAD
Dieser Befehl führt einen neuen Commit aus, welcher die Änderungen der beiden vorhergehenden Commits zurücksetzt und publiziert.
Was ist der Unterschied zwischen section und div in HTML?
der gebrauch von <section> zeigt, dass der Inhalt innerhalb des tags zu einem Thema gehört und als ein Eintrag gruppiert erscheinen soll.
<div> hat keine inhaltliche bedeutung und wird lediglich verwedet um CSS und JS hooks auf seinen inhalt anzuwenden.
Was (1) bewirkt das folgende Statement und (2) was bedeuten die beiden Trennstriche (--) im Statement?
git checkout d1f3b2c -- test.txt
1. Die Datei test.txt wird in den Zustand versetzt, der demjenigen des Commits d1f3b2c entspricht. So kann man z.B. einen früheren Zustand einer Datei wiederherstellen.
2. Die beiden separat stehenden Trennstriche bedeuten, dass alles was nach ihnen folgt keine Optionen des git-Befehls (hier: git checkout) sind. So könnte z.B. auch ein Datei- oder Branchname angegeben werden, der mit zwei Trennstrichen beginnt.
Beispiel:
git branch -D -- --track
Löscht einen Branch, der --track heisst.
Was ist bei Git mit einer "Arbeitskopie" gemeint und wie wird diese erstellt?
Eine Arbeitskopie ist eine lokale Kopie eines Git-Repositories mit welchem entwickelt werden kann. Über "git clone" wird die Arbeitskopie eines "Remote" Git-Repositories erstellt. Dabei wird das Repository mit der gesamten History lokal auf den Rechner geklont (kopiert).
Das Repository kann sich sowohl auf einem Dateiserver (git clone /pfad/zum/git-repository) oder entfernt auf einem Webserver (git clone benutzername@host:/pfad/zum/git-repository) befinden.
Worin unterscheden sich die Befehle "Rebase" und "Merge"
Bei beiden Befehlen werden Codeänderungen von einem Branch mit einem anderen Branch zusammengeführt.
Beim "merge" werden die Codeänderungen von beiden Branches zusammengeführt und danach neu "commited". Die beiden zusammengeführten "Commits" bleiben in der History erhalten und werden entsprechend als Abzweigung dargestellt.
Beim "rebase" werden die Codeänderungen des einen Branches als Basis für die Codeänderungen des anderen Branches genommen und der zusammengeführte "Commit" wird nach dem "rebased" Commit in die History geschrieben. In der History wird nur noch der "rebased" Commit und der neue zusammengeführte Commit in einer Linie angezeigt. Mit dem "rebase" Befehl kann die History linear gehalten werden, jedoch wird die tatsächiche History dadurch verändert.
Was ist git-flow und wann macht es Sinn dieses zu verwenden.
Git-Flow ist ein Branchingmodell welches Git um eine einheitliche Struktur für Projekte erweitert. Dies macht vorallem Sinn wenn mehrere Entwickler an einem Projekt arbeiten. Durch die einzelnen parallel laufenden Branches können mehrere Features gleichzeitig entwickelt werden, sowie auch Releases vorbereitet werden und Hotfixes schnell und einfach durchgeführt werden.
Die sehr genaue Spezifizierung von git-flow hält den Workflow konstant und vereinfacht die einzelnen Entwicklungsprozesse.
Zu den bekannten Hauptbranches “master” und “develop” werden sogennante Support-Branches (Hotfixes, Feature, Release) erstellt, welche später auf verschiedene Art und Weise mit den Hauptzweigen “master” und “develop” automatisch zusammengeführt werden.
Worin unterscheidet sich GIT von anderen herkömmlichen Versionskontrollen? Nenne dazu min. 4 Eigenschaften
1. Nicht-lineare Entwicklung
Sowohl das Erstellen neuer Entwicklungszweige (branching), als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind integraler Bestandteil der Arbeit mit Git und fest in die Git-Werkzeuge eingebaut
2. Kein zentraler Server
Jeder Benutzer besitzt eine lokale Kopie des gesamten Repositorys, inklusive der Versionsgeschichte (history). So können die meisten Aktionen lokal und ohne Netzwerkzugriff ausgeführt werden.
3. Datentransfer zwischen Repositorys
Daten können mit einer Reihe verschiedener Netzwerkprotokolle zwischen Repositorys übertragen werden wie z.B. ssh oder http/https oder eigenes sehr effizientes Protokoll git.
4. Kryptographische Sicherheit der Projektgeschichte
Die Geschichte eines Projektes wird so gespeichert, dass der Hash einer beliebigen Revision (commit) auf der vollständigen Geschichte basiert, die zu dieser Revision geführt hat. Dadurch ist es nicht möglich, die Versionsgeschichte nachträglich zu manipulieren, ohne dass sich der Hash der Revision ändert.
5. Interoperabilität
Es gibt Hilfsprogramme, die Interoperabilität zwischen Git und anderen Versionskontrollsystemen herstellen
6. Verwaltung von Inhalt
Obwohl Git primär zur Versionsverwaltung von Quellcode entwickelt wurde, wird es auch zum Speichern von flach strukturierten (im Gegensatz zu relationalen Strukturen) Datensätzen direkt als Datei genutzt. Die Nutzung ist ähnlich NoSQL, auch wenn Git keine Indexstruktur, Abfrage oder Gleichzeitigkeit erlaubt.
Was versteht man unter "Stashen" ?
Beim Stashen werden die aus dem Arbeitsverzeichnis noch nicht committeten Änderungen, also die geänderten Dateien und die in der Staging-Area enthaltenen Dateien, in einem Stack voller unfertiger Änderungen gespeichert. Diese können jederzeit wieder vom Stack geholt und auf den Arbeitsverzeichnis angewendet werden.Dazu kann der Befehl "git stash" verwendet werden.
In welchen Fällen kann ein umschreiben der History sinnvoll sein und womit ist das möglich?
git rebase (-i interactive) ermöglicht es, einzelne bzw. mehrere commits zusammenzufassen|verwerfen und somit die History des gewählten branches zu ändern. Das ist z.B. sinnvoll, wenn beim realisieren eines neuen Features nicht auf korrekte commit-Meldungen geachtet wurde und dies vor dem rückführen in den master korrigiert werden soll.
Dabei ist zu beachten, dass dies nicht auf einem "öffentlichen" branch geschehen sollte.
Wie kann eine Änderung einer Datei rückgängig gemacht werden ?
Falls noch kein Commit durchgeführt wurde, kann mittels "git checkout <Filename>" die Datei frisch vom Git-Repository geladen werden.
Wurde bereits ein Commit durchgeführt kann dieser mit dem Befehl "git revert" rückgängig gemacht werden.
Unterschied "git pull" und "git fetch"
Was ist der unterschied zwischen „git pull“ und „git fetch“?
- git-fetch lädt die neuen Daten herunter, aber integriert diese nicht. Man hat die Möglichkeit alle Änderungen zu sichten, die auf dem Remote Server gemacht wurden.
- git pull aktualisiert den aktuellen HEAD branch mit den letzten Änderungen vom Remote Server. Die Daten werden nicht nur heruntergeladen sondern auch direkt integriert.
In welchen Fällen ist es sinnvoll, Dateien mit .gitignore von der Versionierung auszunehmen (Beispiel) ?
Alle Dateien, die nicht durch die Softwareentwickler des Projekts verändert werden, müssen nicht versioniert werden.
Dazu gehören z. B.
- log-files aus dem Betrieb
- im Buildprozess vom Präprozessor erstellte Dateien.
(Bei der Entwicklung mit Typescript wären dies alle *.js und *.map Dateien) - Pakete, die über das Internet heruntergeladen werden
(über npm install installierte Pakete im Verzeichnis node_modules)
Du hast eine ältere Git-Revision ausgecheckt und ein File geändert. Warum solltest du die Änderung nicht einchecken?
Wenn du eine ältere Revision auscheckst, befindest du dich im "Detached Head"-Zustand. Damit kannst du frühere Versionen anschauen und experimentelle Änderungen machen. Du solltest aber nicht einchecken, weil nicht die Vergangenheit, sondern nur die aktuellste Version (HEAD) geändert werden sollte. Wenn du auf Basis einer älteren Version weiterentwickeln möchtest, kannst du einen Branch davon erstellen.
Was ist ein Git Commit?
Git Commit ist eine Sammlung (Set of changes) von Änderungen die mit dem Befehl: 'git commit --m "message"' getätigt wird.
Ein Commit ist mit einem 40stelligen eindeutigen identifier benannt (sha1).
Sha-1 ist ein Algorithmus der die Daten der Änderungen als input nimmt und daraus einen hash generiert.
Nach einem Commit wird der HEAD auf diesen letzten Commit im Branch gesetzt.
Bei der Suche nach einem Commit müssen nicht alle 40 Stellen gesetzt werden.Meistens reichen die ersten 15 Stellen..
-
- 1 / 14
-
Cartes-fiches
Wie können z.B. zwei Commits, die bereits gepusht und publiziert wurden wieder rückgängig gemacht werden?
Was passiert dabei technisch gesehen?
git revert HEAD~2..HEAD
Dieser Befehl führt einen neuen Commit aus, welcher die Änderungen der beiden vorhergehenden Commits zurücksetzt und publiziert.
Was ist der Unterschied zwischen section und div in HTML?
der gebrauch von <section> zeigt, dass der Inhalt innerhalb des tags zu einem Thema gehört und als ein Eintrag gruppiert erscheinen soll.
<div> hat keine inhaltliche bedeutung und wird lediglich verwedet um CSS und JS hooks auf seinen inhalt anzuwenden.
Was (1) bewirkt das folgende Statement und (2) was bedeuten die beiden Trennstriche (--) im Statement?
git checkout d1f3b2c -- test.txt
1. Die Datei test.txt wird in den Zustand versetzt, der demjenigen des Commits d1f3b2c entspricht. So kann man z.B. einen früheren Zustand einer Datei wiederherstellen.
2. Die beiden separat stehenden Trennstriche bedeuten, dass alles was nach ihnen folgt keine Optionen des git-Befehls (hier: git checkout) sind. So könnte z.B. auch ein Datei- oder Branchname angegeben werden, der mit zwei Trennstrichen beginnt.
Beispiel:
git branch -D -- --track
Löscht einen Branch, der --track heisst.
Was ist bei Git mit einer "Arbeitskopie" gemeint und wie wird diese erstellt?
Eine Arbeitskopie ist eine lokale Kopie eines Git-Repositories mit welchem entwickelt werden kann. Über "git clone" wird die Arbeitskopie eines "Remote" Git-Repositories erstellt. Dabei wird das Repository mit der gesamten History lokal auf den Rechner geklont (kopiert).
Das Repository kann sich sowohl auf einem Dateiserver (git clone /pfad/zum/git-repository) oder entfernt auf einem Webserver (git clone benutzername@host:/pfad/zum/git-repository) befinden.
Worin unterscheden sich die Befehle "Rebase" und "Merge"
Bei beiden Befehlen werden Codeänderungen von einem Branch mit einem anderen Branch zusammengeführt.
Beim "merge" werden die Codeänderungen von beiden Branches zusammengeführt und danach neu "commited". Die beiden zusammengeführten "Commits" bleiben in der History erhalten und werden entsprechend als Abzweigung dargestellt.
Beim "rebase" werden die Codeänderungen des einen Branches als Basis für die Codeänderungen des anderen Branches genommen und der zusammengeführte "Commit" wird nach dem "rebased" Commit in die History geschrieben. In der History wird nur noch der "rebased" Commit und der neue zusammengeführte Commit in einer Linie angezeigt. Mit dem "rebase" Befehl kann die History linear gehalten werden, jedoch wird die tatsächiche History dadurch verändert.
Was ist git-flow und wann macht es Sinn dieses zu verwenden.
Git-Flow ist ein Branchingmodell welches Git um eine einheitliche Struktur für Projekte erweitert. Dies macht vorallem Sinn wenn mehrere Entwickler an einem Projekt arbeiten. Durch die einzelnen parallel laufenden Branches können mehrere Features gleichzeitig entwickelt werden, sowie auch Releases vorbereitet werden und Hotfixes schnell und einfach durchgeführt werden.
Die sehr genaue Spezifizierung von git-flow hält den Workflow konstant und vereinfacht die einzelnen Entwicklungsprozesse.
Zu den bekannten Hauptbranches “master” und “develop” werden sogennante Support-Branches (Hotfixes, Feature, Release) erstellt, welche später auf verschiedene Art und Weise mit den Hauptzweigen “master” und “develop” automatisch zusammengeführt werden.
Worin unterscheidet sich GIT von anderen herkömmlichen Versionskontrollen? Nenne dazu min. 4 Eigenschaften
1. Nicht-lineare Entwicklung
Sowohl das Erstellen neuer Entwicklungszweige (branching), als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind integraler Bestandteil der Arbeit mit Git und fest in die Git-Werkzeuge eingebaut
2. Kein zentraler Server
Jeder Benutzer besitzt eine lokale Kopie des gesamten Repositorys, inklusive der Versionsgeschichte (history). So können die meisten Aktionen lokal und ohne Netzwerkzugriff ausgeführt werden.
3. Datentransfer zwischen Repositorys
Daten können mit einer Reihe verschiedener Netzwerkprotokolle zwischen Repositorys übertragen werden wie z.B. ssh oder http/https oder eigenes sehr effizientes Protokoll git.
4. Kryptographische Sicherheit der Projektgeschichte
Die Geschichte eines Projektes wird so gespeichert, dass der Hash einer beliebigen Revision (commit) auf der vollständigen Geschichte basiert, die zu dieser Revision geführt hat. Dadurch ist es nicht möglich, die Versionsgeschichte nachträglich zu manipulieren, ohne dass sich der Hash der Revision ändert.
5. Interoperabilität
Es gibt Hilfsprogramme, die Interoperabilität zwischen Git und anderen Versionskontrollsystemen herstellen
6. Verwaltung von Inhalt
Obwohl Git primär zur Versionsverwaltung von Quellcode entwickelt wurde, wird es auch zum Speichern von flach strukturierten (im Gegensatz zu relationalen Strukturen) Datensätzen direkt als Datei genutzt. Die Nutzung ist ähnlich NoSQL, auch wenn Git keine Indexstruktur, Abfrage oder Gleichzeitigkeit erlaubt.
Was versteht man unter "Stashen" ?
Beim Stashen werden die aus dem Arbeitsverzeichnis noch nicht committeten Änderungen, also die geänderten Dateien und die in der Staging-Area enthaltenen Dateien, in einem Stack voller unfertiger Änderungen gespeichert. Diese können jederzeit wieder vom Stack geholt und auf den Arbeitsverzeichnis angewendet werden.Dazu kann der Befehl "git stash" verwendet werden.
In welchen Fällen kann ein umschreiben der History sinnvoll sein und womit ist das möglich?
git rebase (-i interactive) ermöglicht es, einzelne bzw. mehrere commits zusammenzufassen|verwerfen und somit die History des gewählten branches zu ändern. Das ist z.B. sinnvoll, wenn beim realisieren eines neuen Features nicht auf korrekte commit-Meldungen geachtet wurde und dies vor dem rückführen in den master korrigiert werden soll.
Dabei ist zu beachten, dass dies nicht auf einem "öffentlichen" branch geschehen sollte.
Wie kann eine Änderung einer Datei rückgängig gemacht werden ?
Falls noch kein Commit durchgeführt wurde, kann mittels "git checkout <Filename>" die Datei frisch vom Git-Repository geladen werden.
Wurde bereits ein Commit durchgeführt kann dieser mit dem Befehl "git revert" rückgängig gemacht werden.
Unterschied "git pull" und "git fetch"
Was ist der unterschied zwischen „git pull“ und „git fetch“?
- git-fetch lädt die neuen Daten herunter, aber integriert diese nicht. Man hat die Möglichkeit alle Änderungen zu sichten, die auf dem Remote Server gemacht wurden.
- git pull aktualisiert den aktuellen HEAD branch mit den letzten Änderungen vom Remote Server. Die Daten werden nicht nur heruntergeladen sondern auch direkt integriert.
In welchen Fällen ist es sinnvoll, Dateien mit .gitignore von der Versionierung auszunehmen (Beispiel) ?
Alle Dateien, die nicht durch die Softwareentwickler des Projekts verändert werden, müssen nicht versioniert werden.
Dazu gehören z. B.
- log-files aus dem Betrieb
- im Buildprozess vom Präprozessor erstellte Dateien.
(Bei der Entwicklung mit Typescript wären dies alle *.js und *.map Dateien) - Pakete, die über das Internet heruntergeladen werden
(über npm install installierte Pakete im Verzeichnis node_modules)
Du hast eine ältere Git-Revision ausgecheckt und ein File geändert. Warum solltest du die Änderung nicht einchecken?
Wenn du eine ältere Revision auscheckst, befindest du dich im "Detached Head"-Zustand. Damit kannst du frühere Versionen anschauen und experimentelle Änderungen machen. Du solltest aber nicht einchecken, weil nicht die Vergangenheit, sondern nur die aktuellste Version (HEAD) geändert werden sollte. Wenn du auf Basis einer älteren Version weiterentwickeln möchtest, kannst du einen Branch davon erstellen.
Was ist ein Git Commit?
Git Commit ist eine Sammlung (Set of changes) von Änderungen die mit dem Befehl: 'git commit --m "message"' getätigt wird.
Ein Commit ist mit einem 40stelligen eindeutigen identifier benannt (sha1).
Sha-1 ist ein Algorithmus der die Daten der Änderungen als input nimmt und daraus einen hash generiert.
Nach einem Commit wird der HEAD auf diesen letzten Commit im Branch gesetzt.
Bei der Suche nach einem Commit müssen nicht alle 40 Stellen gesetzt werden.Meistens reichen die ersten 15 Stellen..
