Workflow für Software-Entwicklung

Workflows im Bereich der Software-Entwicklung sollten auf GIT-Repositories und einem Ticket-System basieren (Beides über unseren Git Server möglich). Der Fortschritt lässt sich dann anhand des DECK-Karten-Systems (Nextcloud) organisieren (Zeitliche Planung, Priorisierung, etc.) und verfolgen.

Demnach sollte jede die Software-Entwicklung betreffende Karte bezeichnet sein durch

• eine Ticket-Nummer,
• eine Bezeichnung gemäß der conventional-commits-Konvention, gefolgt von einer Beschreibung,

nach dem folgenden Modell-Beispiel des XR/Solaris-Projekts:

Ticket #1: feat(storage): Convert Max coll files to Max Dictionaries.

Git-flow ist ein Branching-Modell, bei dem zwei Branches von wesentlicher Bedeutung sind, um den Verlauf eines Projekts abzubilden: die master-Branch zeichnet die Historie der verschiedenen Software-Releases auf, während die develop-Branch als kontinuierliche Entwicklungsbranch zur Integration jeweiliger Features, Fixes, etc. (auf resp. Branches) dient. Im Folgenden sind grundlegende Arbeitsschritte für ein Gitflow-Workflow aufgelistet:

• Erstellung eines Repositories, z.B. mit Admin-Rechten über Gitblit.

• Klonen des Repositories mit dem Befehl
  git clone [URL des Repositories],
  gefolgt von einer Initialisierung des Repositories für Git-flow mit dem Befehl
  git flow init.
  

• Zur Initialisierung von git-flow werden in diesem Schritt die Namen der oben erwähnten master- und develop-Branches festgelegt. Auf die Anfrage
  Branch name for production releases: [master]
  sollte ein Name für die Branch, die für Releases verwendet wird, eingegeben werden; auf die Anfrage
  Branch name for „next release“ development: [develop]
  ein Name für die Branch, die für Entwicklungen verwendet wird.
  

• Abschließend werden noch die Prefixes für Feature-Branches
  Feature branches? [feature/],
  Release-Branches
  Release branches? [release/]
  und Hotfix-Branches
  Hotfix branches? [hotfix/]
  festgelegt.

(Bild: Vincent Driessen, Creative Commons

1. auf Gitblit ein Repository anlegen
2. einen lokalen Repository-Ordner erzeugen
3. run git flow init: es wird ein erster commit erzeugt
4. add ein Remote-Repository: git remote add origin /path
5. füge dem lokalen Ordner ein .gitignore hinzu
6. füge dem lokalen Ordner alle Quelldateien hinzu
7. run git add -A
8. erzeuge einen commit git commit -m „chore: adding all files to repository.“
9. push alles auf das Repository git push -u origin develop

Repositories können ebenfalls über das Menü rechts oben angelegt werden. Der Name des Repositories kann hierarchisch angegeben werden, um Repositorie-Gruppen zu erstellen, z.B. cs-tools/spatconvert. Anschließend können Berechtigungen gesetzt werden sowie readme.md- und .gitignore-Dateien erzeugt werden.

Wenn ein bereits lokal angelegtes Repository existiert, das auf den Server übertragen und dort verwaltet werden soll, kann dies mit remote add und push auf den Server übertragen werden. Die folgenden Befehle erstellen ein lokales Repository und einen Commit. Sofern bereits ein Repository mit Commits existiert, kann dieser Schritt übersprungen werden:

mkdir remote-add-test
cd remote-add-test/
git init
echo test > test.txt
git add test.txt
git commit -m „Initial commit“

Die Übertragung auf den Server funktioniert folgendermaßen:

git remote add origin https://[user]@git.marlonschumacher.net/r/remote-add-test.git
git remote -v
git push -u origin master

Hierbei muss user mit dem eigenen Nutzernamen ersetzt werden. Der Name des Repositories (hier remote-add-test) sollte ebenfalls ersetzt werden, er sollte aber mit dem Namen des lokalen Ordners konsistent gehalten werden.

• Versionsnummern sollten dem Regelwerk des Semantic-Versioning-Schemes folgen.
• Naming-Schemes für Branches befinden sich hier und hier.

Commenting in LISP code (linting, pre-commit hooks, etc.):

• 3 semicolons for comment on new line outside of code body (not more than 3 consecutive lines of comments ever)
• 2 semicolons for comment within code body
• 1 semicolon for outcommenting code

• Link zur Gitblit-Seite: https://git.marlonschumacher.de/
  
• Referenz zu Git: https://git-scm.com/docs
  
• Referenzen zu Gitflow:
  • https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
  • https://splitshade.wordpress.com/2012/04/22/git-flow-einfaches-arbeiten-mit-dem-perfekten-git-workflow/
  • https://github.com/marketplace/actions/gitflow-workflow-action
  • https://www.gitkraken.com/blog/gitflow
• Referenz zu Semantic-Versioning: https://semver.org
• Referenzen zu Naming-Schemes für Branches:
  • https://davidwalsh.name/git-branch-autocompletion
  • https://codingsight.com/git-branching-naming-convention-best-practices/
• Für Admins: Referenzen zu Server und Administrationsoberfläche von Gitblit: Administration von Gitblit