Git ist eine Sammlung von Werkzeugen zur Versionsverwaltung von Dateien.
\nIm Laufe der Arbeit an Dateien (z.B. Programm-Code) kann damit jeder Entwicklungsstand eines Projektes festgehalten werden.<\/p>\n
Dezentrale Repositories – Clones<\/em><\/p>\n<\/li>\n Dokumentation<\/a><\/p>\n<\/li>\n<\/ul>\n GIT kann die Koordination von Team-Arbeit an gemeinsamen Projekten unterst\u00fctzen.<\/p>\n GIT bietet aber auch praktische M\u00f6glichkeiten, wenn man es alleine nutzt.<\/p>\n Prinzipiell kann mit git jegliches Dateiformat verwaltet werden, allerdings funktionieren diff<\/em>, merge<\/em> etc. am besten mit rein textbasierten Dateiformaten (also Programm-Quelltext, HTML, LaTEX, usw.). Ein Repository ist der “Beh\u00e4lter”, in dem das Projekt mitsamt allen seinen Daten, Meta-Informationen und Versionen enthalten ist.<\/p>\n Man unterscheidet zwischen non bare<\/em> Repositories – sie enthalten einen Arbeitsbereich (also die Dateien an denen gearbeitet werden kann) und bare<\/em> Repositories – sie enthalten die kompletten Daten und Infos eines Projektes, aber keinen Arbeitsbereich; sie sind sozusagen als Server-Repositories gedacht; in der Regel kann nur in bare<\/em> Repos gepusht<\/em> werden (s.u.).<\/p>\n W\u00e4hrend in einigen anderen SCMs zwischen Arbeitsbereich und Repository unterschieden wird, verschwimmen in Git die Grenzen ein wenig. Ein Clone<\/em> eines Repositories enth\u00e4lt immer den kompletten Satz an Informationen \u00fcber das Projekt. Ein Clone<\/em> kann ein “Arbeitsbereich” sein oder aber auch als Repository dienen.<\/p>\n Der Arbeitsbereich ist der Ordner, in dem sich mein Clone<\/em> oder mein Projekt befindet. Hier habe ich alle Dateien, die zum Projekt geh\u00f6ren und kann \u00c4nderungen vornehmen. Bei der Team-Arbeit an einem Projekt gibt es meist einen oder mehrere Server, auf denen die (Haupt-) Repos liegen, sogenannte ‘remotes’. Zum arbeiten clone<\/em> ich das remote Repo, arbeite daran. F\u00fcr Neulinge meist etwas verwirrend ist bei git das Konzept der Staging Area<\/em>. Wenn ich in meinem Arbeitsbereich \u00c4nderungen vorgenommen habe, werden diese normalerweise committed<\/em>, i.e. die \u00c4nderungen werden in das Respository \u00fcbernommen. Illustration: Zust\u00e4nde von Dateien<\/a><\/p>\n Mit einem Wenn ich mit einem geclonten Repo arbeite und meine \u00c4nderungen auch den remote Repositories (ich kann beliebig viele remote Repositories verwalten) mitteilen m\u00f6chte, tue ich das mit einem Ein g\u00e4ngiges Verfahren ist, zu Beginn seiner Arbeit einen neuen Zweig, einen Arbeits-Branch zu erstellen, so bleibt mein urspr\u00fcnglicher Branch erhalten und ich kann jederzeit zum Vergleich hin- und her-schalten. Sind alle \u00c4nderungen zur Zufriedenheit vorgenommen, stage<\/em> und commite<\/em> ich meine Arbeit (noch im Arbeitsbranch). Daraufhin kann ich meinen Arbeitsbranch in den urspr\u00fcnglichen Branch mergen<\/em> – d.h. Arbeits- und urspr\u00fcnglicher Branch werden zusammengef\u00fchrt. RTFM<\/a><\/p>\n Initialisiert ein neues Repo in Git Buch – Ein Git-Repository anlegen<\/a><\/p>\n Will man stattdessen ein bereits existierendes Repo benutzen, \u2026<\/p>\n Erzeugt einen lokalen Clone<\/em> des entsprechenden Repos auf GitHub.<\/p>\n Git Buch – Eein existisrendes Repository klonen<\/a><\/p>\n Nachdem alle \u00c4nderungen vorgenommen wurden, \u2026<\/p>\n oder<\/p>\n um alles zu stagen.<\/p>\n Danach dann mit<\/p>\n alle gestageten \u00c4nderungen in Repo \u00fcbernehmen. Ein commit \u00f6ffnet in der Regel den Editor zum Verfassen der commit-Message; eine leere Meldung bricht den commit ab. Git Buch – \u00c4nderungen am Repository nachverfolgen<\/a><\/p>\n Um aktuell die Arbeit in einem neuen Branch zu beginnen bzw. fortzusetzen, nutzt man Dies erzeugt einen neuen Branch und wechselt sofort in diesen. Git Buch – Git Branching<\/a><\/p>\n Vor der Arbeit an einem Projekt, an dem auch andere Team-Mitglieder arbeiten, empfiehlt es sich, Informationen \u00fcber von anderen vorgenommen \u00c4nderungen zu erneuern: Bevor man die Arbeit an einem bestimmten Branch fortsetzt, holt man sich die jew. aktuellen \u00c4nderungen mit Git Buch – Mit externen Repositorys arbeiten<\/a><\/p>\n Mit kann man sich die History – das Log \u00fcber die bisher vorgenommenen \u00c4nderungen – betrachten. kann man sich Informationen \u00fcber den aktuellen Zustand des Arbeitsbereichs anzeigen lassen.<\/p>\n Git Buch – \u00c4nderungen am Repository nachverfolgen<\/a><\/p>\n Habe ich die \u00c4nderungen in einem Arbeitsbranch abgeschlossen (i.e. gestaget und commitet), wechsle ich zur\u00fcck in meinen Ausgangsbranch und merge<\/em> die \u00c4nderungen meines Arbeitsbranches: Letzter Befehl l\u00f6scht meinen Arbeitsbranch wieder.<\/p>\n Gibt es keine parallelen \u00c4nderungen, findet ein Fast Forward Merge<\/em> statt – d.h. nur der “HEAD-Zeiger” wird aktualisiert.<\/p>\n Haben parallel \u00c4nderungen stattgefunden, wird ein 3-Wege-Merge angewendet, bei dem die \u00c4nderungen seit dem letzten gemeinsamen Vorfahren verschmolzen werden. Dies kann u.U. zu Konflikten f\u00fchren, die manuell aufgel\u00f6st werden m\u00fcssen.<\/p>\n Um meine \u00c4nderungen in ein Remote zu \u00fcbertragen, wird gepusht<\/em>: Git Buch – \u00c4nderungen in ein Remote Repository hochladen<\/a><\/p>\n Jeder Snapshot eines Repos wird mit einer (md5) Hashsumme versehen und ist auf diese Weise referenzierbar. Tags<\/em> k\u00f6nnen auch auf ein Remote gepusht werden. Zudem ist es m\u00f6glich ein Tag mit seinem PGP\/GPG Key zu signieren.<\/p>\n Git Buch – Tags<\/a><\/p>\n Was ist GIT? Git ist eine Sammlung von Werkzeugen zur Versionsverwaltung von Dateien. Im Laufe der Arbeit an Dateien (z.B. Programm-Code) kann damit jeder Entwicklungsstand eines Projektes festgehalten werden. Es kann (fast) nichts verloren gehen – Snapshot, History Es k\u00f6nnen nebeneinander verschiedene Versionen eines Projekts gepflegt werden (man m\u00f6chte bspw. etwas ausprobieren, was sp\u00e4ter gegebenenfalls … Continue reading GIT Versionsverwaltung<\/span> Wozu sollte ich GIT benutzen?<\/h3>\n
\n
Wof\u00fcr eignet sich git nicht so gut<\/h4>\n
\nBin\u00e4re Datenformate (Bilder, Audio, Video, komprimierte Textformate (doc)) lassen sich auch mit git verwalten, allerdings kann bei ihnen bspw. ein Merge-Konflikt nur gel\u00f6st werden, indem sich f\u00fcr eine der beiden Versionen entschieden wird, ein Verschmelzen beider Dateien ist nich ohne weiteres m\u00f6glich.<\/p>\nWas unterscheidet GIT von anderen VCS?<\/h3>\n
\n
Begriffe \/ Konzepte hinter GIT<\/h3>\n
Repository<\/h4>\n
Arbeitsbereich (Clone)<\/h4>\n
\nEin Clone<\/em> ist ein Projekt, das von einem remote Repository ‘geholt’ wurde; s\u00e4mtliche Informationen \u00fcber Versionen, Branches etc. sind darin enthalten – ich verf\u00fcge sozusagen \u00fcber das komplette Projekt mit allen Versionen aller Dateien, die es je gegebn hat.<\/p>\n(Fetch\/Pull – Arbeitsbereich updaten)<\/h4>\n
\nWenn andere Team-Mitglieder auch an dem Projekt arbeiten, entstehen dadurch \u00c4nderungen, die mein Clone<\/em> noch nicht kennt; diese muss ich vom remote anfordern.
\ngit fetch<\/code> holt die Informationen \u00fcber alle seit dem letzten fetch<\/em> geschehenen \u00c4nderungen.
\ngit pull<\/code> merget<\/em> mir die so mitgeteilten \u00c4nderungen in einen bestimmten Branch<\/em><\/p>\nStaging Area (\u00c4nderungen f\u00fcr Commit vormerken)<\/h4>\n
\nIn git gibt es jedoch zuvor eine Zwischenstufe, die Staging Area<\/em>; ein commit<\/em> ber\u00fccksichtigt (im Normalfall) nur alle \u00c4nderungen, die sich in der Staging Area<\/em> (auch Index<\/em>) befinden.
\nMeine \u00c4nderungen an Dateien in meinem Projekt landen nicht automatisch in der Staging Area, ich muss sie explizit mit einem ‘add’ dorthin bef\u00f6rdern.
\nObwohl das auf den ersten Blick etwas umst\u00e4ndlich erscheint, ist es aber ein m\u00e4chtiges Werkzeug:<\/p>\n\n
git commit -a<\/code> den ganzen Staging Kram \u00fcberspringen \ud83d\ude09<\/li>\n<\/ul>\nCommit (\u00c4nderungen lokal \u00fcbernehmen)<\/h4>\n
git commit<\/code> \u00fcbernehme ich die gestageten<\/em> \u00c4nderungen in das lokale Repository.<\/p>\nPush (\u00c4nderungen in ein remote Repo \u00fcbertragen)<\/h4>\n
git push<\/code>.<\/p>\nBranch – \u00c4nderungszweig erstellen; Neues ausprobieren, altes bleibt bestehen.<\/h4>\n
\nPraktisch ist es auch, w\u00e4hrend der Arbeit ggf. weitere Branches erstellen, um verschiedene Versionen einer \u00c4nderung anzuschauen – auch wieder ohne Einflussnahme auf den urspr\u00fcnglichen Branch.
\nNeu angelegte Branches sind zun\u00e4chst “privat” – also nur im lokalen Repo\/Clone – es sei denn, sie werden explizit in ein remote Repo gepusht<\/em>.<\/p>\nMerge – \u00c4nderungszweige zusammenf\u00fchren<\/h4>\n
\nSind keine weiteren parallelen \u00c4nderungen geschehen, gen\u00fcgt ein Fast Forward Merge<\/em> – dabei wird nur der HEAD-Zeiger weiterger\u00fcckt.
\nGab es auch parallele \u00c4nderungen, wird ein 3-Wege-Merge<\/em> durchgef\u00fchrt (basierend auf den jeweiligen \u00c4nderungen seit dem letzen gemeinsamen Vorfahren) – was evtl. zu Merge-Konflikten<\/em> f\u00fchren kann, wenn bspw. zwei unterschiedliche \u00c4nderungen an ein und dem selben Abschnitt einer Datei vorgenommen wurden, was dann manuell aufgel\u00f6st werden muss.<\/p>\nWie fange ich an?<\/h2>\n
Hilfe<\/h3>\n
git help [<Kommando>]<\/code><\/p>\nEin neues Repository erzeugen<\/h3>\n
git init <verzeichnis><\/code><\/p>\n
\nDas Verzeichnis muss nicht leer sein, so kann ein bestehendes Projekt leicht in die git Versionsverwaltung eingebunden werden.
\nEvtl. vorhandene Dateien (auch das Verzeichnis selbst) sind noch nicht gestaget<\/em>! Am besten wird nach dem Initialisieren eine erste Version erzeugt:
\ncd <verzeichnis>
\ngit add .
\ngit commit -m 'Initial commit'<\/code><\/p>\nEin Repository clonen<\/h3>\n
git clone https:\/\/github.com\/AliTe\/experimini_20151021_git.git<\/code><\/p>\n\u00c4nderungen vornehmen<\/h3>\n
git add <datei><\/code><\/p>\ngit add -A<\/code><\/p>\ngit commit<\/code><\/p>\n
\nEs bew\u00e4hrt sich in der commit message in der ersten Zeile eine kurze Zusammenfassung der vorgenommenen \u00c4nderungen zu schreiben, dann eine Leerzeile und dann ggf. etwas ausf\u00fchrlicheren Text. Viele Tools zeigen in \u00dcbersichts-Ansichten dann nur die erste Zeile an und gew\u00e4hren so einen kompakten \u00dcberblick.<\/p>\nEinen Branch anlegen<\/h3>\n
\ngit checkout -b <neuer Branchname><\/code><\/p>\n
\nEinen Branch erzeugen, ohnen ihn auch gleich auszuchecken geht mit:
\ngit branch <neuer Branchname><\/code><\/p>\nArbeitsbereich updaten: Fetch und Pull<\/h3>\n
\ngit fetch [<remote>|--all]<\/code><\/p>\n
\ngit pull<\/code><\/p>\nDie History betrachten<\/h3>\n
\ngit log<\/code><\/p>\n
\nMit
\ngit status<\/code><\/p>\nMergen<\/h3>\n
\ngit checkout <Ausgangsbranch>
\ngit merge <Arbeitsbranch>
\ngit branch -d <Arbeitsbranch><\/code><\/p>\n\u00c4nderungen in ein Remote Repository pushen<\/h3>\n
\ngit push <remote> <Branchname><\/code><\/p>\nTaggen<\/h3>\n
\nM\u00f6chte man einen Snapshot explizit markieren (z.B. ein Milestone des Projektes, eine Release-Nummer o.\u00e4.) kann man dazu einen Tag<\/em> setzen:
\ngit tag <tagname><\/code><\/p>\nPraktische Tools und Tipps<\/h3>\n
\n
Weiterf\u00fchrende Techniken \/ Konzepte<\/h2>\n
\n
![Illustration: Zust\u00e4nde von Dateien<\/a><\/p>\nCommit (\u00c4nderungen lokal \u00fcbernehmen)<\/h4>\nMit einem git commit<\/code> \u00fcbernehme ich die gestageten<\/em> \u00c4nderungen in das lokale Repository.<\/p>\nPush (\u00c4nderungen in ein remote Repo \u00fcbertragen)<\/h4>\nWenn ich mit einem geclonten Repo arbeite und meine \u00c4nderungen auch den remote Repositories (ich kann beliebig viele remote Repositories verwalten) mitteilen m\u00f6chte, tue ich das mit einem git push<\/code>.<\/p>\nBranch – \u00c4nderungszweig erstellen; Neues ausprobieren, altes bleibt bestehen.<\/h4>\nEin g\u00e4ngiges Verfahren ist, zu Beginn seiner Arbeit einen neuen Zweig, einen Arbeits-Branch zu erstellen, so bleibt mein urspr\u00fcnglicher Branch erhalten und ich kann jederzeit zum Vergleich hin- und her-schalten.\nPraktisch ist es auch, w\u00e4hrend der Arbeit ggf. weitere Branches erstellen, um verschiedene Versionen einer \u00c4nderung anzuschauen – auch wieder ohne Einflussnahme auf den urspr\u00fcnglichen Branch.\nNeu angelegte Branches sind zun\u00e4chst “privat” – also nur im lokalen Repo\/Clone – es sei denn, sie werden explizit in ein remote Repo gepusht<\/em>.<\/p>\nMerge – \u00c4nderungszweige zusammenf\u00fchren<\/h4>\nSind alle \u00c4nderungen zur Zufriedenheit vorgenommen, stage<\/em> und commite<\/em> ich meine Arbeit (noch im Arbeitsbranch). Daraufhin kann ich meinen Arbeitsbranch in den urspr\u00fcnglichen Branch mergen<\/em> – d.h. Arbeits- und urspr\u00fcnglicher Branch werden zusammengef\u00fchrt.\nSind keine weiteren parallelen \u00c4nderungen geschehen, gen\u00fcgt ein Fast Forward Merge<\/em> – dabei wird nur der HEAD-Zeiger weiterger\u00fcckt.\nGab es auch parallele \u00c4nderungen, wird ein 3-Wege-Merge<\/em> durchgef\u00fchrt (basierend auf den jeweiligen \u00c4nderungen seit dem letzen gemeinsamen Vorfahren) – was evtl. zu Merge-Konflikten<\/em> f\u00fchren kann, wenn bspw. zwei unterschiedliche \u00c4nderungen an ein und dem selben Abschnitt einer Datei vorgenommen wurden, was dann manuell aufgel\u00f6st werden muss.<\/p>\nWie fange ich an?<\/h2>\nRTFM<\/a><\/p>\nHilfe<\/h3>\ngit help [<Kommando>]<\/code><\/p>\nEin neues Repository erzeugen<\/h3>\ngit init <verzeichnis><\/code><\/p>\nInitialisiert ein neues Repo in , i.e. legt den Ordner \/.git an, in dem die Versionsdatenbank etc. liegt.\nDas Verzeichnis muss nicht leer sein, so kann ein bestehendes Projekt leicht in die git Versionsverwaltung eingebunden werden.\nEvtl. vorhandene Dateien (auch das Verzeichnis selbst) sind noch nicht gestaget<\/em>! Am besten wird nach dem Initialisieren eine erste Version erzeugt:\ncd <verzeichnis>\ngit add .\ngit commit -m 'Initial commit'<\/code><\/p>\nGit Buch – Ein Git-Repository anlegen<\/a><\/p>\nEin Repository clonen<\/h3>\nWill man stattdessen ein bereits existierendes Repo benutzen, \u2026<\/p>\ngit clone https:\/\/github.com\/AliTe\/experimini_20151021_git.git<\/code><\/p>\nErzeugt einen lokalen Clone<\/em> des entsprechenden Repos auf GitHub.<\/p>\nGit Buch – Eein existisrendes Repository klonen<\/a><\/p>\n\u00c4nderungen vornehmen<\/h3>\nNachdem alle \u00c4nderungen vorgenommen wurden, \u2026<\/p>\ngit add <datei><\/code><\/p>\noder<\/p>\ngit add -A<\/code><\/p>\num alles zu stagen.<\/p>\nDanach dann mit<\/p>\ngit commit<\/code><\/p>\nalle gestageten \u00c4nderungen in Repo \u00fcbernehmen. Ein commit \u00f6ffnet in der Regel den Editor zum Verfassen der commit-Message; eine leere Meldung bricht den commit ab.\nEs bew\u00e4hrt sich in der commit message in der ersten Zeile eine kurze Zusammenfassung der vorgenommenen \u00c4nderungen zu schreiben, dann eine Leerzeile und dann ggf. etwas ausf\u00fchrlicheren Text. Viele Tools zeigen in \u00dcbersichts-Ansichten dann nur die erste Zeile an und gew\u00e4hren so einen kompakten \u00dcberblick.<\/p>\nGit Buch – \u00c4nderungen am Repository nachverfolgen<\/a><\/p>\nEinen Branch anlegen<\/h3>\nUm aktuell die Arbeit in einem neuen Branch zu beginnen bzw. fortzusetzen, nutzt man\ngit checkout -b <neuer Branchname><\/code><\/p>\nDies erzeugt einen neuen Branch und wechselt sofort in diesen.\nEinen Branch erzeugen, ohnen ihn auch gleich auszuchecken geht mit:\ngit branch <neuer Branchname><\/code><\/p>\nGit Buch – Git Branching<\/a><\/p>\nArbeitsbereich updaten: Fetch und Pull<\/h3>\nVor der Arbeit an einem Projekt, an dem auch andere Team-Mitglieder arbeiten, empfiehlt es sich, Informationen \u00fcber von anderen vorgenommen \u00c4nderungen zu erneuern:\ngit fetch [<remote>|--all]<\/code><\/p>\nBevor man die Arbeit an einem bestimmten Branch fortsetzt, holt man sich die jew. aktuellen \u00c4nderungen mit\ngit pull<\/code><\/p>\nGit Buch – Mit externen Repositorys arbeiten<\/a><\/p>\nDie History betrachten<\/h3>\nMit\ngit log<\/code><\/p>\nkann man sich die History – das Log \u00fcber die bisher vorgenommenen \u00c4nderungen – betrachten.\nMit\ngit status<\/code><\/p>\nkann man sich Informationen \u00fcber den aktuellen Zustand des Arbeitsbereichs anzeigen lassen.<\/p>\nGit Buch – \u00c4nderungen am Repository nachverfolgen<\/a><\/p>\nMergen<\/h3>\nHabe ich die \u00c4nderungen in einem Arbeitsbranch abgeschlossen (i.e. gestaget und commitet), wechsle ich zur\u00fcck in meinen Ausgangsbranch und merge<\/em> die \u00c4nderungen meines Arbeitsbranches:\ngit checkout <Ausgangsbranch>\ngit merge <Arbeitsbranch>\ngit branch -d <Arbeitsbranch><\/code><\/p>\nLetzter Befehl l\u00f6scht meinen Arbeitsbranch wieder.<\/p>\nGibt es keine parallelen \u00c4nderungen, findet ein Fast Forward Merge<\/em> statt – d.h. nur der “HEAD-Zeiger” wird aktualisiert.<\/p>\nHaben parallel \u00c4nderungen stattgefunden, wird ein 3-Wege-Merge angewendet, bei dem die \u00c4nderungen seit dem letzten gemeinsamen Vorfahren verschmolzen werden. Dies kann u.U. zu Konflikten f\u00fchren, die manuell aufgel\u00f6st werden m\u00fcssen.<\/p>\n\u00c4nderungen in ein Remote Repository pushen<\/h3>\nUm meine \u00c4nderungen in ein Remote zu \u00fcbertragen, wird gepusht<\/em>:\ngit push <remote> <Branchname><\/code><\/p>\nGit Buch – \u00c4nderungen in ein Remote Repository hochladen<\/a><\/p>\nTaggen<\/h3>\nJeder Snapshot eines Repos wird mit einer (md5) Hashsumme versehen und ist auf diese Weise referenzierbar.\nM\u00f6chte man einen Snapshot explizit markieren (z.B. ein Milestone des Projektes, eine Release-Nummer o.\u00e4.) kann man dazu einen Tag<\/em> setzen:\ngit tag <tagname><\/code><\/p>\nTags<\/em> k\u00f6nnen auch auf ein Remote gepusht werden. Zudem ist es m\u00f6glich ein Tag mit seinem PGP\/GPG Key zu signieren.<\/p>\nGit Buch – Tags<\/a><\/p>\nPraktische Tools und Tipps<\/h3>\n\n.gitignore \/ .gitkeep<\/li>\n.gitconfig lokal\/global<\/li>\nSubmodules \/ Subtrees<\/li>\n<\/ul>\nWeiterf\u00fchrende Techniken \/ Konzepte<\/h2>\n\nGitflow<\/li>\nGitHub\/GitLab\/Bitbucket<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"Was ist GIT? Git ist eine Sammlung von Werkzeugen zur Versionsverwaltung von Dateien. Im Laufe der Arbeit an Dateien (z.B. Programm-Code) kann damit jeder Entwicklungsstand eines Projektes festgehalten werden. Es kann (fast) nichts verloren gehen – Snapshot, History Es k\u00f6nnen nebeneinander verschiedene Versionen eines Projekts gepflegt werden (man m\u00f6chte bspw. etwas ausprobieren, was sp\u00e4ter gegebenenfalls … Continue reading GIT Versionsverwaltung<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":20,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-269","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/pages\/269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=269"}],"version-history":[{"count":1,"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/pages\/269\/revisions"}],"predecessor-version":[{"id":270,"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/pages\/269\/revisions\/270"}],"up":[{"embeddable":true,"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=\/wp\/v2\/pages\/20"}],"wp:attachment":[{"href":"https:\/\/www.experimini.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"http:\/\/git-scm.com\/figures\/18333fig0201-tn.png\"){kind=link}