====== Workflow für Software-Entwicklung ======

Workflows im Bereich der Software-Entwicklung sollten auf GIT-Repositories und einem Ticket-System basieren (Beides über unseren [[https://git.marlonschumacher.de/|Git Server]] möglich). Der Fortschritt lässt sich dann anhand des [[workflows:kanban-deck|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 //[[https://www.conventionalcommits.org/de/v1.0.0/|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''.


----

===== Workflow mit Git-flow =====

[[https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow|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 [[https://git.marlonschumacher.de/|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.

[{{ gitflow-model.001.png?360 | (Bild: [[https://nvie.com/posts/a-successful-git-branching-model/|Vincent Driessen]], Creative Commons }}]


----

===== Workflow mit Gitblit =====

==== Template zum Erstellen eines Sourcecode-Repositories ====

  - auf [[https://git.marlonschumacher.de|Gitblit]]  ein Repository anlegen
  - einen lokalen Repository-Ordner erzeugen
  - //run// ''git flow init'': es wird ein erster //commit// erzeugt
  - //add// ein Remote-Repository: ''git remote add origin /path''
  - füge dem lokalen Ordner ein ''.gitignore'' hinzu
  - füge dem lokalen Ordner alle Quelldateien hinzu
  - //run// ''git add -A''
  - erzeuge einen //commit// ''git commit -m "chore: adding all files to repository."''
  - //push// alles auf das Repository ''git push -u origin develop''


==== Repositories Anlegen ====
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.


==== Bestehende Repositories auf den Server Pushen ====
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.

==== Versioning/Tagging und Naming-Schema für Branches ====

  * Versionsnummern sollten dem Regelwerk des [[https://semver.org|Semantic-Versioning-Schemes]] folgen.
  * Naming-Schemes für Branches befinden sich [[https://davidwalsh.name/git-branch-autocompletion|hier]] und [[https://codingsight.com/git-branching-naming-convention-best-practices/|hier]].


----

===== Coding Style Guide ===== 

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


----

===== Referenzen ===== 

  * 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: [[admin:admin-gitblit|Administration von Gitblit]]


{{tag>Gitblit Git-flow Ticket Software-Entwicklung Repository Semantic-Versioning Coding-Style-Guide}}