{ "version": "https://jsonfeed.org/version/1.1", "title": "fboës - Der Blog | Artikel mit dem Tag \"Git\"", "home_page_url": "https://journal.3960.org/", "feed_url": "https://journal.3960.org/tagged/git/feed.json", "description": "Programmierung, Luft- & Raumfahrt, Kurioses: Der Blog von und mit Frank Boës.", "icon": "https://cdn.3960.org/favicon-192x192.png", "favicon": "https://cdn.3960.org/images/tile-128x128.png", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org" } ], "language": "de-DE", "_rss": { "about": "http://cyber.harvard.edu/rss/rss.html", "copyright": "© 2008-2023 Creative Commons BY" }, "items": [ { "id": "user/posts/2021-08-27-merge-einen-git-branch-abgekuerzt/index.md", "url": "https://journal.3960.org/posts/2021-08-27-merge-einen-git-branch-abgekuerzt/", "title": "Merge in einen Git-Branch – abgekürzt", "content_html": "
Ob man nun Gitflow, GitHub Flow oder ein selbstausgedachte Abwandlung dieser Modelle verwendet: Einige dieser Modelle benötigen einen Weg, um einen Branch in einen anderen Branch zu mergen. Dieser Handgriff ist in Git mehrteilig – und teilweise etwas nervig.
\n\nGit sieht dafür den Weg vor, in den Ziel-Branch zu wechseln (z.B. main
), und vom Quell-Branch (z.B. feature/XYZ
) mittels git merge
zu ziehen. Das ist in der Regel eine sehr gute Methode, um Fehlbedienungen zu vermeiden.
Bei vielen Git-Workflows wird nun aber davon ausgegangen, dass im Ziel-Branch nicht direkt gearbeitet werden soll. Es ist also sehr wichtig, nach Abschluss des Merges wieder in den Quell-Branch zu wechseln, um dort versehentliche Commits zu vermeiden. Die verschiedenen Branch-Wechsel bedürfen also einiger Konzentration.
\nZudem ist die Schreibarbeit für einen solchen Merge auf der Kommandozeile etwas umfangreicher, will man nichts übersehen und vor allen Dingen alle Zwischenschritte auch auf dem Repo-Server bzw. origin
bekannt machen:
$ git push\n$ git checkout main\n$ git pull\n$ git merge feature/XYZ\n$ git push\n$ git checkout feature/XYZ\n
\nTatsächlich gibt es für Gitflow die Gitflow-CLI-Tools, die genau dieses Problem lösen:
\n$ git flow feature finish feature/XYZ\n
\nDummerweise haben diese Tools den Nachteil, dass das Ziel der Operation fest verdrahtet ist – und außerdem die Installation der Tools voraussetzt. In der Regel scheitert es bei mir daran, dass in dem Projekt gar nicht Gitflow verwendet wird. 😉
\nDer Wunsch ist also: Ein leichtgewichtiges, flexibles Tool, dass sicher einen Quell-Branch in einen Ziel-Branch merged.
\nNicht zuletzt durch die beeindruckende Sammlung von Bash Aliases meines Kollegen Marty kam ich auf die Idee, für meine Wünsche ebenfalls einen Bash-Alias zu schreiben. Analog zu Git Aliases (zu denen ich meine persönliche Sammlung von Git Aliases angelegt habe) kann man mittels Bash-Aliases neue Befehle für die Bash erzeugen.
\nIm einfachsten Fall sind Bash-Aliases Aufrufe, die komplizierte Einzeiler ersetzen. Meine Idee war etwas komplexer, so dass ich stattdessen eine Bash Function verwendet habe, um meine Idee umzusetzen. Ich hatte die folgende Vorstellung:
\nSollten Merge Conflicts auftreten, würde das Programm abbrechen und Gelegenheit zur Korrektur des Konflikts geben.
\nDas finale Script (die aktuellste Version findet sich auch in meinen öffentlichen .bash_aliases
) sieht nun wie folgt aus:
# Put me in `.bash_aliases`, works like an alias.\ngit-merge-to() {\n TARGET_BRANCH=develop\n if [[ "${1}" ]]; then\n TARGET_BRANCH=${1}\n fi\n\n FEATURE_BRANCH=$(git branch | sed -n -e 's/^\\* \\(.*\\)/\\1/p')\n\n if [[ ! "${FEATURE_BRANCH}" ]]; then\n echo -e "\\e[91mERROR\\e[0m: No git branch found"\n return 4\n fi\n if [[ "${FEATURE_BRANCH}" =~ ^(main|master|develop|preview)$ ]]; then\n echo -e "\\e[91mERROR\\e[0m: Branch ${FEATURE_BRANCH} is not a mergable branch"\n git branch\n return 2\n fi\n if [[ "${FEATURE_BRANCH}" == "${TARGET_BRANCH}" ]]; then\n echo -e "\\e[91mERROR\\e[0m: Branches are identical"\n return 3\n fi\n\n echo -en "Merge branch \\e[94m${FEATURE_BRANCH}\\e[0m into \\e[94m${TARGET_BRANCH}\\e[0m? [yn] "\n read CONFIRM\n if [[ ! "${CONFIRM}" =~ ^(y|Y|yes|Yes)$ ]]; then\n echo "Cancelled"\n return 1\n fi\n\n git push\n git checkout ${TARGET_BRANCH}\n git pull\n git merge ${FEATURE_BRANCH} --no-edit\n git push\n git checkout ${FEATURE_BRANCH}\n}\n
\nSobald dieses Script in der .bash_aliases
eingetragen ist, kann man es auf dem lokalen Rechner von jedem Ort aus starten:
$ git-merge-to develop\nMerge branch feature/web-components into develop? [yn] y\n Everything up-to-date\n Switched to branch 'develop'\n Your branch is up-to-date with 'origin/develop'.\n Already up-to-date.\n Merge made by the 'recursive' strategy.\n Writing objects: 100% (6/6), 578 bytes | 578.00 KiB/s, done.\n Switched to branch 'feature/web-components'\n Your branch is up-to-date with 'origin/feature/web-components'.\n$\n
\nNetterweise funktioniert auch die Auto-Vervollständigung des Befehles mittels der Tabulatoren-Taste, so dass ein git-
und TAB den Befehl anzeigt.
SSH-Schlüssel sind die Eintrittskarte für SSH, Git, und viele andere darauf aufbauende, nützliche Dienste, die ein Programmierer nutzen möchte. Während unter Linux und Mac OSX das Erzeugen eines SSH-Schlüssels eine schmerzlose Sache ist, sind unter Windows mehr Handgriffe gefragt, um alle Anwendungsfälle eines SSH-Schlüssels abbilden zu können – unter anderem für die Verwendung des selben Schlüssels aus einer Virtualisierung wie zum Beispiel VirtualBox oder Docker.
\n\nGenerell gibt es zwei Arten, unter Windows einen SSH-Schlüssel zu speichern:
\nppk
)Viele Anleitungen beschränken sich auf die eine oder andere Methode zum Anlegen von SSH-Schlüsseln. Tatsächlich macht es aber unter Windows sehr viel Sinn, den eigenen Schlüssel in beiden Formate verfügbar zu haben. Das geht deutlich schmerzloser, wenn beide Schlüsselformate in einem Aufwasch angelegt werden.
\nputtygen
Schlüsselgenerator, pageant
Schlüsselagenten und das plink
SSH-Verbindungstool.mkdir -p ~/.ssh
angelegt werden.C:\\Users\\USERNAME\\.ssh
) die insgesamt drei Dateien anzulegen, die zusammen alle Schlüssel-Komponenten darstellen.In PuttyGen selber wird es nun etwas trickreich:
\nC:\\Users\\USERNAME\\.ssh\\id_rsa.ppk
speichern.C:\\Users\\USERNAME\\.ssh\\id_rsa.pub
einfügen (mit der Funktion „Save public key“ wird der Public Key nicht im korrekten Format exportiert).C:\\Users\\USERNAME\\.ssh\\id_rsa
speichern. Wichtig ist hierbei, dass keine Dateiendung verwendet wird.In eurem SSH-Verzeichnis C:\\Users\\USERNAME\\.ssh
sollten nun mindestens drei Dateien liegen:
id_rsa.ppk # Privater / öffentlicher Schlüssel für PuTTY\nid_rsa.pub # Öffentlicher Schlüssel für OpenSSH\nid_rsa # Privater Schlüssel für OpenSSH\n
\nSpäter werden in diesem Verzeichnis ggf. noch mehr Dateien auftauchen, wie z.B. known_hosts
, authorized_keys
und config
.
Übrigens solltet ihr mit der Git Bash mittels chmod 644 ~/.ssh/* && chmod 600 ~/.ssh/id_rsa
allen Dateien die korrekten Zugriffsrechte (-rw-r--r--
bzw. -rw-------
) geben, falls dies nicht schon geschehen ist.
Den öffentlichen Schlüssel könnt ihr nun auf allen Servern und Diensten bekannt machen, mit denen ihr euch später verbinden wollt. Auf eurem Rechner wiederum wird die Git Bash automatisch den privaten OpenSSH-Schlüssel verwenden, während andere Programme den privaten Schlüssel aus der id_rsa.ppk
entweder in den Einstellungen übergeben bekommen müssen, oder aber aus einem vorher zu startenden pageant
Schlüsselagenten übernehmen können. Falls ihr SSH-Schlüssel für eure tägliche Arbeit benutzt, könnt ihr den Pageant auch automatisch starten und den Schlüssel laden lassen.
Viele Windows-Programme können so euren SSH-Schlüssel nutzen, u.a.:
\nSo oder so seid ihr nun mit beiden Schlüsselformaten ausgestattet, so dass z.B. auch der Wechsel des Betriebssystems oder die Verwendung von Virtualisierung euch die Weiterbenutzung eures SSH-Schlüssels erlaubt.
\nUnter Linux und Mac OSX ist der Vorgang übrigens etwas kürzer:
\nssh-keygen -t rsa -b 4096 -C "YOUR@EMAIL"\n
",
"summary": "SSH-Schlüssel sind die Eintrittskarte für SSH, Git, und viele andere darauf aufbauende, nützliche Dienste, die ein Programmierer nutzen möchte. Während unter…",
"date_published": "2019-12-30T18:52:10+01:00",
"date_modified": "2020-07-29T07:07:13+02:00",
"author": {
"name": "Frank Boës",
"url": "mailto:info@3960.org",
"avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca"
},
"authors": [
{
"name": "Frank Boës",
"url": "mailto:info@3960.org",
"avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca"
}
],
"banner_image": "https://journal.3960.org/posts/2019-12-30-ssh-schluessel-unter-windows-komplett/puttygen.png",
"language": "de-DE",
"image": "https://journal.3960.org/posts/2019-12-30-ssh-schluessel-unter-windows-komplett/puttygen.png",
"tags": [
"Für Tumblr",
"Programmierung",
"Webdevelop",
"Git",
"Bash",
"Anleitung"
]
},
{
"id": "user/posts/2018-09-19-umstieg-auf-microsoft-visual-studio-code/index.md",
"url": "https://journal.3960.org/posts/2018-09-19-umstieg-auf-microsoft-visual-studio-code/",
"title": "Der Umstieg auf Microsoft Visual Studio Code",
"content_html": "\nMein Kollege Slawo hat mich schon vor geraumer Zeit auf einen interessanten Code-Editor hingewiesen: Microsofts Visual Studio Code (oder kurz „VS Code“). Microsofts Charme-Offensive in Richtung der Developer-Community hat ein ganz neues Werkzeug hervorgebracht, dass es mit den etablierten Konkurrenten vom Range eines Sublime Text, Atom und Co aufnehmen soll.
\n\nLange Jahre war Sublime Text 2 bzw. 3 mein Lieblings-Code-Editor. Vor allen Dingen die hohe Geschwindigkeit beim Tippen als auch die unglaublich schnelle Suche machten für mich lange Jahre die Benutzung einer echten IDE überflüssig. Mit Hilfe von unzähligen Sublime-Plugins habe ich mich da inzwischen sehr gemütlich eingerichtet.
\nBeruflich bin ich aber inzwischen bei PhpStorm angelangt, und habe mich da an bestimmten Luxus gewöhnt. Hervorragendes Auto-Complete bzw. die Verlinkung von Objekten im Quellcode, die direkte Anzeige von Fehlern oder die Integration von SQL, Git und Terminals vermisste man dann und wann doch in Sublime Text. Dafür war mir bei PhpStorm schon immer seine Behäbigkeit und sein Ressourcenhunger für das heimische Arbeiten ein Gräuel.
\nWonach ich also suchte ist die Spritzigkeit von Sublime Text 3, und die integrierte Arbeitsweise und Unterstützung von PhpStorm. Für mich selber habe ich mit Microsoft Visual Studio Code den perfekten Kompromiss gefunden – zumal dieser Kompromiss keinen Cent kostet.
\n\nSublime Text 3 ist der schnellste Klappspaten unter den Editoren, während PhpStorm das Äquivalent eines Braunkohletagebaubaggers ist.
Damit entspricht Microsofts Visual Studio Code einem Bobcat-Bagger.
Meine Highlights bei VS Code:
\nPersönlich wechsele ich ungern meine Werkzeuge aus, wenn ich nicht einen echten Grund dafür verspüre. Ich werfe gerne ein Auge auf die Trends in diesem Bereich, ohne andauernd den Drang zu verspüren, alles selber ausprobieren zu müssen. Außerdem möchte ich eigentlich wenig Zeit mit meinen Werkzeugen, sondern lieber mit meiner Arbeit verbringen. Umso größer ist für mich also der Schritt, meinen Code-Editor auszutauschen – das zentrale Werkzeug, dass meine Ideen in ausführbaren Code verwandelt.
\nWie bei jedem Editor-Wechsel war am Anfang etwas Fremdeln angesagt. Chris Coyiers Artikel über den Umstieg auf VS Code hat mir zum Glück gerade noch rechtzeitig die Möglichkeit erläutert, mit einem Plugin das Verhalten von VS Code in einigen relevanten Bereichen (z.B. Tastaturkürzel) einfach auf das Verhalten von Sublime Text 3 abzuändern.
\nVS Code nutze ich daheim aktuell für folgende Projekt-Typen:
\nÜberraschenderweise ist VS Code für Windows, Mac OSX und Linux verfügbar.
\nDirekt nach der Installation stellt man überrascht fest, dass es eigentlich nicht viele Plugins braucht; VS Code hat unglaublich viele Funktionalitäten von vorne herein integriert. So ist für die Verwendung von Gulp, Grunt, Sass, ESlint, Php-Debuggern und vielen anderen Notwendigkeiten des Webentwickler-Lebens bereits Vorsorge getroffen. Selbst eine Live-Preview von Markdown, ein Terminal und Git ist integriert. Daher ist meine persönliche Liste von zusätzlichen Plugins relativ bescheiden:
\n/**
automatisch für den dahinter liegenden Code-Abschnitt einen PhpDoc-Kommentar erzeugen lassen.Für viele verschiedene Programmieraufgaben stellt Microsoft Tutorials für VS Code bereit. Die Palette der im Standard unterstützten Sprachen von VS Code reicht dabei von HTML, CSS, JavaScript und PHP über Node.js hin zu C#, C/C++, ohne das diese Liste erschöpfend alle unterstützten Sprachen enthält.
\nIn Kombination mit der Erweiterbarkeit und der Möglichkeit, Kommandozeilentools in VS Code einzubinden, steht dem geneigten Entwickler so ziemlich jede Sprache bequem zur Verfügung.
\nÜbrigens sieht Visual Studio Live Share sehr spannend aus: Hier können mehrere Programmierer zusammen in Echtzeit ein und dieselbe Datei bearbeiten. Das habe ich persönlich zwar noch nicht ausprobiert, Youtube-Videos davon sehen aber sehr interessant aus:
\n\nMeine persönlichen Einstellungen in der settings.json
…
{\n "editor.fontSize": 13,\n "editor.formatOnPaste": false,\n "editor.formatOnSave": false,\n "editor.largeFileOptimizations": false,\n "editor.multiCursorModifier": "ctrlCmd",\n "editor.renderWhitespace": "boundary",\n "editor.rulers": [80, 120],\n "editor.snippetSuggestions": "top",\n "editor.tabSize": 2,\n "editor.useTabStops": false,\n "editor.wordWrap": "on",\n "explorer.confirmDelete": false,\n "files.autoSave": "onFocusChange",\n "files.eol": "\\n",\n "files.exclude": {\n ".idea": true,\n ".vscode": true\n },\n "git.autofetch": true,\n "git.enableSmartCommit": true,\n "git.path": "C:\\\\Program Files\\\\Git\\\\bin\\\\git.exe",\n "npm.enableScriptExplorer": true,\n "spellright.documentTypes": [\n "markdown",\n "latex",\n "plaintext"\n ],\n "terminal.integrated.shell.windows": "C:\\\\Program Files\\\\Git\\\\bin\\\\bash.exe",\n "workbench.colorTheme": "Monokai",\n "php.validate.executablePath": "C:\\\\xampp\\\\php\\\\php.exe",\n "editor.defaultFormatter": "esbenp.prettier-vscode"\n}\n
\n…und der keybindings.json
…
[\n { "key": "ctrl+g", "command": "editor.action.nextMatchFindAction" },\n { "key": "ctrl+7", "command": "editor.action.commentLine", "when": "editorTextFocus && !editorReadonly" },\n { "key": "ctrl+shift+7", "command": "editor.action.blockComment", "when": "editorFocus" },\n { "key": "ctrl+shift+d", "command": "editor.action.copyLinesDownAction", "when": "editorFocus" },\n { "key": "ctrl+d", "command": "editor.action.addSelectionToNextFindMatch", "when": "editorFocus" },\n { "key": "ctrl+h", "command": "editor.action.startFindReplaceAction" },\n { "key": "ctrl+shift+up", "command": "editor.action.moveLinesUpAction" },\n { "key": "ctrl+shift+down", "command": "editor.action.moveLinesDownAction" }\n]\n
\n…sind direkte Übernahmen des Verhaltens, dass ich mir schon für Sublime Text 3 überlegt hatte. Viel mehr Konfiguration ist dann nicht mehr nötig.
\nBei meinen ersten Versuchen scheiterte ich daran, den in VS Code integrierten Git-Client zum Laufen zu bringen. Obwohl auf der Kommandozeile und auch in einem lokal installierten Source Tree alles ganz wunderbar lief, wehrte sich VS Code gegen git push
und git pull
mit dem Hinweis, dass der Git-Server meine Credentials nicht mochte. Die Lösung dafür war aber gar nicht so komplex:
Die Voraussetzungen für die Benutzung von Git direkt aus Microsofts Visual Studio Code ist die Installation von Git Credential Manager (bei neuerem Git wird dies automatisch mit dabei sein) und Plink von Putty, dass den SSH-Schlüssel für Git bereitstellt.
\nAußerdem sollte eine globale Systemvariable vorhanden sein, die auf plink.exe
verweist. Das kann man mit der Windows Eingabeaufforderung erledigen:
set GIT_SSH="C:\\Program Files\\PuTTY\\plink.exe"\nsetx GIT_SSH %GIT_SSH%\necho %GIT_SSH%\n
\nSobald der SSH-Schlüssel in Pageant geladen ist, kann VS Code auch problemlos alle Git-Kommandos ausführen.
\nFür meine heimische Arbeit ist Microsofts Visual Studio Code der würdige Nachfolger von Sublime Text 3. Er ist nicht nur kostenlos, sondern lässt mich (fast) so schnell wie mit Sublime Text 3 arbeiten, während er gleichzeitig viele Annehmlichkeiten einer echten IDE mitbringt.
", "summary": "Mein Kollege Slawo hat mich schon vor geraumer Zeit auf einen interessanten Code-Editor hingewiesen: Microsofts Visual Studio Code (oder kurz „VS Code“).…", "date_published": "2018-09-19T19:42:47+02:00", "date_modified": "2020-02-27T10:17:00+01:00", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" } ], "banner_image": "https://journal.3960.org/posts/2018-09-19-umstieg-auf-microsoft-visual-studio-code/visual-code.png", "language": "de-DE", "image": "https://journal.3960.org/posts/2018-09-19-umstieg-auf-microsoft-visual-studio-code/visual-code.png", "tags": [ "Git", "PHP", "Programmierung", "Review", "Webdevelop" ] }, { "id": "user/posts/2018-07-19-git-werkzeugkiste.md", "url": "https://journal.3960.org/posts/2018-07-19-git-werkzeugkiste/", "title": "Meine Git-Werkzeugkiste", "content_html": "Wie jeder Programmierer habe auch ich meine kleine Sammlung an Werkzeugen, die meine Arbeit schneller machen. Da man als Entwickler ab und zu auf einen neuen Rechner umzieht, lohnt es sich, diese Werkzeuge für sich selber zu dokumentieren, um sie auf dem nächsten Rechner wieder schnell aufsetzen zu können.
\nÄhnlich wie bei meinen Standard-Einstellungen in Sublime Text 3 habe ich für Git inzwischen jede Menge Einstellungen und Aliase erzeugt, die ich inzwischen auf jedem meiner Rechner im Einsatz habe.
\n\nDie Einstellungen werden einfach direkt von der Kommandozeile aus eingetragen, indem man die folgenden Zeilen ausführt:
\n#!/bin/bash\ngit config --global user.name "YOUR NAME"\ngit config --global user.email "YOURMAIL@example.com"\ngit config --global tag.sort version:refname\ngit config --global core.autocrlf false # https://stackoverflow.com/a/13154031/3232532\ngit config --system core.longpaths true # https://stackoverflow.com/a/22575737/3232532\ngit config --global alias.chmod 'update-index --add --chmod=+x' # FILE: Makes files executable in Git\ngit config --global alias.reset-unpushed 'reset HEAD~1' # Undo last commits which have not been pushed\ngit config --global alias.reset-pushed 'revert HEAD' # Undo last commits which have been pushed\ngit config --global alias.reset-ultra '!f() { git reset --hard && git clean -f -d; }; f' # Undo everything before last commit\ngit config --global alias.tag-current 'describe --tags' # Shows current tag\ngit config --global alias.tag-sorted 'tag --sort=v:refname' # Show tags sorted\ngit config --global alias.remove-keep 'rm --cached -r' # FILE: Remove from Git but keep locally\ngit config --global alias.acp '!f() { git add -A && git commit -m "$@" && git push; }; f' # Add, commit, push, https://stackoverflow.com/a/35049625/3232532\ngit config --global alias.delete-dangle '!f() { git fetch -p && for branch in `git branch -vv | grep ": gone]" | awk "{print $1}"`; do git branch -D $branch; done; }; f' # https://stackoverflow.com/questions/7726949/remove-tracking-branches-no-longer-on-remote\ngit config --global alias.graph 'log --oneline --graph' # Show commits as graph\n\n# git show: Diff of latest commit\n# git branch -r: Show all branches\n# git merge --abort: Abort merge ;)\n
\nGerade ein Git Alias spart mit der Zeit Unmengen an Nachschlage- und Denkarbeit, und dient nebenbei als gute Dokumentation für die Lösung komplexer Git-Probleme.
", "summary": "Wie jeder Programmierer habe auch ich meine kleine Sammlung an Werkzeugen, die meine Arbeit schneller machen. Da man als Entwickler ab und zu auf einen neuen…", "date_published": "2018-07-19T19:40:55+02:00", "date_modified": "2020-04-01T09:14:16+02:00", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" } ], "banner_image": "https://cdn.3960.org/favicon-192x192.png", "language": "de-DE", "image": "https://cdn.3960.org/favicon-192x192.png", "tags": [ "Git", "Programmierung", "Webdevelop", "Für Tumblr" ] }, { "id": "user/posts/2018-04-25-wie-sieht-gute-commit-message-git-aus.md", "url": "https://journal.3960.org/posts/2018-04-25-wie-sieht-gute-commit-message-git-aus/", "title": "Wie sieht eine gute Commit-Message in Git aus?", "content_html": "Mit dem Artikel „How to Write a Git Commit Message“ habe ich meinen persönlichen Stil für eine gute Git-Commit-Message weiter verfeinert. Für mich sieht eine gute Commit-Message nun wie folgt aus:
\nKurz-Zusammenfassung (max. 50 Zeichen), als Aufforderung geschrieben, ohne Punkt am Ende\n\nOptional: Erweiterte Markdown-Beschreibung, abgetrennt durch eine Leerzeile.\nDer Text der gesamten Commit-Message ist dabei in Englisch.\n
\nUnd wenn ihr ein Ticket-System verwendet, solltet ihr die Ticket-Nummer in die Commit-Message mit aufnehmen:
\nKurz-Zusammenfassung (max. 50 Zeichen), als Aufforderung geschrieben, refs TICKET-NUMMER\n\nOptional: Erweiterte Markdown-Beschreibung, abgetrennt durch eine Leerzeile.\nDer Text der gesamten Commit-Message ist dabei in Englisch.\n
\nJüngstes Beispiel vom Blogophon:
\nAdd CSS variable `--gallery-count` to gallery HTML\n\nCheck https://css-tricks.com/simple-swipe-with-vanilla-javascript/ on what to do with that.\n
\nAber ehrlich gesagt ist der Artikel „How to Write a Git Commit Message“ die bisher beste und umfassendste Antwort auf die Frage nach einer guten Commit-Message.
", "summary": "Mit dem Artikel „How to Write a Git Commit Message“ habe ich meinen persönlichen Stil für eine gute Git-Commit-Message weiter verfeinert. Für mich sieht eine…", "date_published": "2018-04-25T20:14:41+02:00", "date_modified": "2018-07-17T12:43:40+02:00", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" } ], "banner_image": "https://cdn.3960.org/favicon-192x192.png", "language": "de-DE", "image": "https://cdn.3960.org/favicon-192x192.png", "external_url": "https://chris.beams.io/posts/git-commit/", "tags": [ "Git", "Meinung", "Programmierung", "Webdevelop" ] }, { "id": "user/posts/2017-11-20-schnelle-deployments-mit-gitlab.md", "url": "https://journal.3960.org/posts/2017-11-20-schnelle-deployments-mit-gitlab/", "title": "Schnelle Deployments mit Gitlab", "content_html": "Ihr habt eine Gitlab-Instanz in eurer Firma stehen? Ihr wollt mit Deployments anfangen, habt aber keine Lust auf Jenkins? Überraschung: Mit Gitlab könnt ihr auch Deployments durchführen!
\n\nSchon lange sind die Zeiten vorbei, in denen man einfach via FTP Dateien vom heimischen Rechner auf den Kundenserver hochschieben sollte. Wenn ihr händisch mittels rsync
oder git
Quellcode auf Develop-, Staging- oder Produktiv-System schiebt, ist der Sprung zu einem automatischen Deployment gar nicht mehr so weit, wenn ihr Gitlab verwendet.
Warum solltet ihr automatische Deployments verwenden?
\nNachfolgend findet ihr ein Deployment via git
, ohne weitere Zusätze. Nachdem das Prinzip verstanden ist, kann das Rezept auch für rsync
, npm
, composer
oder jede andere Form von Transportmethode angepasst werden, und um beliebige andere schlaue Handgriffe erweitert werden.
Ein Git-Deployment sieht für euch normalerweise wie folgt aus:
\ngit clone
das Projekt ausgecheckt war.git pull
(plus ggf. weitere Kommandos durch).Genau diese Handgriffe führt ein Gitlab-Deployment für euch automatisch durch, wenn bestimmte Bedingungen im Git erfüllt sind. In der Regel ist diese Bedingung ein Commit in einen bestimmten Branch, oder das Auftauchen eines neuen Tags.
\nFalls ihr der ganzen Automatik nicht traut, könnt ihr auch festlegen, dass das Deployment mit einem Knopf aus dem Webfrontend von Gitlab gestartet wird.
\nDreh- und Angelpunkt ist das installierte Gitlab-CI-Modul von Gitlab. Dies wird eurer lokalen Gitlab-Installation hinzugefügt. Danach könnt ihr jedes eurer Projekte mit einer Datei namens gitlab-ci.yml
ausstatten, in der ihr das Deployment beschreibt.
Meine Vorlage dafür sieht inzwischen wie folgt aus:
\n# Never use Docker image without pinned version\nimage: governmentpaas/git-ssh:f120938e7390ec36314ec037465a1b35a079243e\n\nbefore_script:\n - eval $(ssh-agent -s)\n - mkdir -p ~/.ssh\n - echo "${SSH_CONFIG}" > ~/.ssh/config\n - echo "${SSH_KNOWNHOSTS}" > ~/.ssh/known_hosts\n - ssh-add <(echo "${SSH_PRIVATEKEY}")\n\n# Hier könnte Testing durchgeführt werden.\n# Das Deployment wird nur durchgeführt, wenn der Test erfolgreich ist.\n# test:\n# image: cytopia/eslint\n# stage: test\n# only:\n# - master\n# - merge_requests\n# script:\n# - tools/ci/test.sh\n\ndeploy_production:\n stage: deploy\n environment:\n name: production\n url: ${PRODUCTION_URL}\n variables:\n ENVIRONMENT_HOST: ${CI_ENVIRONMENT_NAME}\n ENVIRONMENT_DIR: ${PRODUCTION_DIR}\n ENVIRONMENT_URL: ${PRODUCTION_URL}\n only:\n - master\n # - tags\n # when: manual\n script:\n #- ssh ${ENVIRONMENT_HOST} "cd ${ENVIRONMENT_DIR} && echo 'Start DB backup...'"\n - ssh ${ENVIRONMENT_HOST} "cd ${ENVIRONMENT_DIR} && git pull && git checkout ${CI_COMMIT_SHA} ."\n #- ssh ${ENVIRONMENT_HOST} "cd ${ENVIRONMENT_DIR} && echo 'Clear cache...'"\n\n# deploy_staging:\n# deploy_develop:\n# Hier könnten weitere Deployments für andere Zielsysteme stehen,\n# die man einfach von "deploy_production" kopieren kann\n
\nIn dem Skript sind die Schritte für Building und Testing aktuell ausgeklammert, können von euch aber einfach aktiviert werden. Der eigentliche Clou ist hier, dass Gitlab mit einigen von euch hinterlegten Variablen in der letzten Zeile der Datei aufgefordert wird, eine SSH-Verbindung zu dem Zielhost aufzumachen und dort ein git checkout
durchzuführen.
Die eigentliche Magie ist dabei, dass Gitlab exakt den aktuellen ausgewählten Commit auf dem betreffenden Zielsystem auscheckt. Mit der direktive only
legt ihr z.B. einen bestimmten Branch oder ein Tag fest, mit when: manual
eine manuelle Ausführung. Und im Falle eines verpfuschten Deployments, könnt ihr aus dem Gitlab-Webfrontend auch einen älteren Commit deployen lassen!
Das Deployment-Skript lässt sich natürlich um weitere Kommandos erweitern, die man auf dem Zielsystem ausführen möchte. Caches leeren, Composer ausführen oder Backups anlegen – all dies kann man hier problemlos hinzufügen. Und außerdem sehr ihr bereits, wie man z.B. für ein Develop- oder Staging-System das Skript erweitern könnt. Mehr Informationen über das Thema findet ihr in der offizielen Gitlab-CI-Dokumentation.
\nDas obige Deployment-Skript ist ohne große Änderungen für viele Projekte verwendbar. Pro Projekt hinterlegt man in Gitlab nur noch ein paar Pipeline-Settings:
\nVariable | \nInhalt | \n
---|---|
SSH_CONFIG | \nHier muss eine SSH-Config z.B. für production hinterlegt werden. Siehe unten. | \n
SSH_KNOWNHOSTS | \nHier muss das Ergebnis von ssh-keyscan [-p PORT] HOSTNAME für jeden der Hosts in SSH_CONFIG hinterlegt werden. | \n
SSH_PRIVATEKEY | \nDer SSH-Key, mit dem sich Gitlab zum Produktions-System verbinden darf. | \n
PRODUCTION_URL | \nDie URL, unter der das Produktions-System erreichbar ist. | \n
PRODUCTION_DIR | \nDer Pfad, in dem die Produktions-Installation liegt. | \n
Die letzten drei Variablen kann man ggf. noch für DEVELOP_
und STAGING_
ausführen.
Die Variable SSH_CONFIG
benutzt einen kleinen Trick, um die für das Deployment notwendigen SSH-Zugangsdaten zu speichern: Eine sehr kompakte Art und Weise, um Serverdaten inklusive Ports, Benutzernamen und IPs aufzulisten, ist die SSH-Config. Für Gitlab kann man dieses Format ganz wunderbar verwenden, um die Server-Konfiguration für die Deployment-Server in einer Pipeline-Variable zu hinterlegen.
Host production\n Hostname 192.168.178.12\n Port 22\n User www-data\n
\nZu beachten ist dabei, dass in der SSH-Config keine Passwörter gespeichert werden können. Das ist aber auch in Ordnung, da man sinnigerweise die Authentifizierung des Zugangs über einen SSH-Schlüssel durchführt.
\nNachdem all diese Handgriffe vollbracht sind, könnt ihr im Idealfall 30 Sekunden nach eurem Commit bereits euren Quellcode auf der jeweiligen Zielumgebung bewundern. Projektmanager und Tester werden es euch danken, jederzeit den aktuellsten Stand auf dem Entwicklungssystem vorzufinden – und ihr werdet es euch selber danken, beim Deployment nicht das Backup vergessen zu haben. 😉
\nAußerdem müsst ihr dem Rest des Teams nicht großartig erklären, wie Deployments jetzt funktionieren: Jedes Teammitglied, dass Git benutzt, kann ohne weiteres Vorwissen mustergültige Deployments hinlegen.
\nUpdate: Inzwischen gibt es eine überarbeitete Version des Artikels „Fehlerfreie Gitlab-Deployments für Shopware & Co“ auf den Seiten meines Arbeitgebers.
", "summary": "Ihr habt eine Gitlab-Instanz in eurer Firma stehen? Ihr wollt mit Deployments anfangen, habt aber keine Lust auf Jenkins? Überraschung: Mit Gitlab könnt ihr…", "date_published": "2017-11-20T19:00:00+01:00", "date_modified": "2020-01-23T14:53:21+01:00", "author": { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" }, "authors": [ { "name": "Frank Boës", "url": "mailto:info@3960.org", "avatar": "https://www.gravatar.com/avatar/71fcf51cf2ae9acdd54182d3e367ceca" } ], "banner_image": "https://cdn.3960.org/favicon-192x192.png", "language": "de-DE", "image": "https://cdn.3960.org/favicon-192x192.png", "tags": [ "Git", "Webdevelop", "Programmierung", "Bash" ] } ] }