NETWAYS · martialblog · Apr 12, 2023 · Mar 31, 2023 · Mar 31, 2023 · Mar 31, 2023
diff --git a/day2/01_Workflows/01_Intro.md b/day2/01_Workflows/01_Intro.md
@@ -1,19 +1,10 @@
 !SLIDE subsection
 # ~~~SECTION:MAJOR~~~ Git Workflows
 
-
 !SLIDE smbullets
-# Git Workflows
+# Git Workflows Overview
 
 * Single user environments
 * Multiple users working together
 * Branching models
 * Merge and pull request workflow integration
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
diff --git a/day2/01_Workflows/03_Feature_Branch.md b/day2/01_Workflows/03_Feature_Branch.md
@@ -1,10 +1,10 @@
 !SLIDE smbullets noprint
 # Feature Branch Workflow
 
-* Feature development happens in named branches
+* Development happens in named branches
 * Does not interfere with the main codebase
 * Main branch does not contain broken code
-* Feature branches can be rebased against stable main branch on demand
+* Branches can be rebased against the main branch on demand
 
 <center><img src="../../_images/mermaid/workflow-branches.mmd.png" alt="Feature Branch Workflow"/></center>
 
@@ -14,33 +14,18 @@
 * Feature development happens in named branches
 * Does not interfere with the main codebase
 * Main branch does not contain broken code
-* Feature branches can be rebased against stable main branch on demand
+* Branches can be rebased against stable main branch on demand
 
 <center><img src="../../_images/mermaid/workflow-branches.mmd.png" alt="Feature Branch Workflow" width="75%" /></center>
 
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
 !SLIDE smbullets
 # Feature Branch Workflow - How it works
 
-* Create a new branch for each feature
-* Descriptive branch names, e.g. `feature/docs-workflows`
-* Changes in a feature branch similar to centralized workflow
-* Push feature branches to central repository for collaboration with other developers
-
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
+* Create a new branch every time you start new work
+* Use descriptive branch names (`feature/new-login`, `fix/db-error`)
+* Branch names can mirror issue names and numbers (`feature/new-login-1`)
+* Changes within a branch are similar to the centralized workflow
+* Push branches to central repository for collaboration with other developers
 
 !SLIDE smbullets
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Use Feature Branches
@@ -53,12 +38,6 @@
  * Add and commit changes
  * Push the branch to your central repository
 
-~~~SECTION:handouts~~~
-
-****
-
-~~~ENDSECTION~~~
-
 !SLIDE supplemental exercises
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Use Feature Branches
 
@@ -124,12 +103,6 @@ The new branch `feature/docs-workflows` will be based on the `main` branch.
  * Checkout the `main` branch, merge the feature branch as non-fast-forward with `--no-ff`
  * Show the history tree with `tig` or inside GitLab and explain why the forced merge commit with `--no-ff` is important
 
-~~~SECTION:handouts~~~
-
-****
-
-~~~ENDSECTION~~~
-
 !SLIDE supplemental exercises
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Merge Feature Branches
 

diff --git a/day2/01_Workflows/04_Gitflow.md b/day2/01_Workflows/04_Gitflow.md
@@ -1,21 +1,11 @@
 !SLIDE smbullets
 # Gitflow Workflow
 
-* Strict branching model for project releases
+Gitflow is a strict branching model for larger projects
+
 * Based on Feature Branch Workflow
-* Assigns roles to different branches
+* It assigns roles to different branches
 * Defines interaction between branches for releases
- * Prepare
- * Maintain
- * Record
-
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
 
 !SLIDE smbullets noprint
 # Gitflow Workflow - Historical Branches
@@ -31,18 +21,10 @@
 
 * Main branch for release history (including version tags)
 * Main branch is always `stable` and in production
-* Develop branch for feature integration
+* Development branch for feature integration
 
 <center><img src="../../_images/mermaid/workflow-historical-branches.mmd.png" alt="Gitflow Workflow" width="75%" /></center>
 
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
 !SLIDE smbullets noprint
 # Gitflow Workflow - Feature Branches
 
@@ -61,13 +43,6 @@
 
 <center><img src="../../_images/mermaid/workflow-feature-branches.mmd.png" alt="Gitflow Workflow" width="85%" /></center>
 
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
-
 !SLIDE smbullets noprint
 # Gitflow Workflow - Release Branches
 
@@ -84,12 +59,6 @@
 
 <center><img src="../../_images/mermaid/workflow-release-branches.mmd.png" alt="Gitflow Workflow" width="85%" /></center>
 
-~~~SECTION:handouts~~~
-
-****
-
-~~~ENDSECTION~~~
-
 !SLIDE smbullets noprint
 # Gitflow Workflow - Maintenance Branches
 
@@ -105,10 +74,3 @@
 * Merged to `main`, tagged and merged to `develop`
 
 <center><img src="../../_images/mermaid/workflow-maintenance-branch.mmd.png" alt="Gitflow Workflow" width="85%" /></center>
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
diff --git a/day2/01_Workflows/05_Gitlab_Workflow.md b/day2/01_Workflows/05_Gitlab_Workflow.md
@@ -18,13 +18,6 @@
 
 <center><img src="../../_images/mermaid/workflow-gitlab-mr.mmd.png" alt="GitLab Workflow" width="75%" /></center>
 
-~~~SECTION:handouts~~~
-
-****
-
-~~~ENDSECTION~~~
-
-
 !SLIDE supplemental solutions
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Proposed Solution
 ****
@@ -92,7 +85,6 @@ branch names, review them and then delete them.
 
 * Run `git fetch --prune` and `git branch -d feature/docs-merge-request`
 
-
 !SLIDE supplemental solutions
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Proposed Solution
 ****
@@ -160,6 +152,3 @@ by merging the MR.
     $ git checkout main
     $ git pull
     $ tig
-
-
-
diff --git a/day2/01_Workflows/08_Practical_Workflow_Examples.md b/day2/01_Workflows/08_Practical_Workflow_Examples.md
@@ -1,44 +1,15 @@
-!SLIDE smbullets small
-# Workflow Examples: Icinga 2
+!SLIDE
+# Workflow Examples: Icinga
 
-* Feature branch workflow
-* `main` as development branch
-* Major releases from `main`, `support/x.y` for bugfix releases
+A mix of feature branch and gitflow workflow.
 
-Moving to GitHub, we extended this to:
+* `master` corresponds to the development branch
+* Major releases are created and tagged on `master`
+* `support/x.y` branches for bugfix releases of long time support releases
 
-* (WIP) Pull Requests, local and community forks
-* Travis CI, GitHub Actions (Linux) & Appveyor (Windows) automated tests
-* Developers review and approve PRs, maintainer merges
-* Maintainer prepares and publishes a release
-
-https://github.com/Icinga/icinga2/blob/master/CONTRIBUTING.md
-
-https://github.com/Icinga/icinga2/blob/master/RELEASE.md
-
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
+Organizational workflow:
 
-
-!SLIDE smbullets small
-# Workflow Examples: Icinga Exchange
-
-* Issue management in GitLab with milestones and boards
-* Developers create Merge Requests from local branches
-* CI jobs run unit and Mock tests (GitHub oauth, etc.)
-* Maintainer reviews MRs and merges
-* Maintainer creates a new release
-* Manual deployment via Puppet and release tags
-
-
-~~~SECTION:handouts~~~
-
-****
-
-
-~~~ENDSECTION~~~
+* Pull Requests, local and community forks
+* Testing via GitHub Actions (Linux) and Appveyor (Windows)
+* Developers review and approve PRs, maintainers merge them
+* Maintainer prepares and publishes a release
diff --git a/day2/01_Workflows/09_Rebase_Squash.md b/day2/01_Workflows/09_Rebase_Squash.md
@@ -1,17 +1,22 @@
 !SLIDE smbullets
-# More Hints: Rebase and Squash
+# Rewriting History: Rebase and Squash
 
-The `git rebase` command can also be used to perform certain
-actions on a specific commit history.
-
-If you are contributing to open source projects developers
-might ask you to either rebase your history or even `squash`
+Developers from open source projects sometimes ask you
+to `rebase` your history or even `squash`
 all commits into one commit.
 
-    commit1  => commit
+Squashing in Git means to combine multiple commits into one.
+
+    commit1 => commit
     commit2
     commit3
 
+This is recommended when you have a lot of WIP commits,
+to clean up your history, so it only has meaningful commits.
+
+`git rebase` can also be used to perform various
+actions on the repository's history.
+
 !SLIDE smbullets
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Rebase and squash commits
 
@@ -104,8 +109,6 @@ from commit messages.
     squash ce90e16 commit2
     squash ed6a68f commit3
 
-
-
 !SLIDE smbullets
 # Lab ~~~SECTION:MAJOR~~~.~~~SECTION:MINOR~~~: Force Push and Protected Branches
 
@@ -143,7 +146,6 @@ Therefore it is advised to protect sensitive branches in the project's repositor
 to make this a permanent setting as administrator, you can e.g. use the REST API
 to always force this setting with a small script and cronjob.
 
-
 ~~~ENDSECTION~~~
 
 !SLIDE supplemental exercises
@@ -196,8 +198,8 @@ and choose `Protected Branches > Expand`.
 Add `main` as protected branch, and set all options to
 `maintainers` again.
 
-!SLIDE smbullets
-# More Hints: Force Push in shared branch, what now?
+!SLIDE
+# Don't Force Push a shared branch
 
 * You pulled the 3 commits now being squashed in main
 * Your colleague force pushed the branch with 1 squashed commit
@@ -210,11 +212,4 @@ Discuss this with the trainer.
     $ git checkout feature/new-backend
     $ git reset --hard origin/feature/new-backend
 
-
-!SLIDE smbullets
-# Alternatives to force push?
-
-* `git revert`
-* Creates a new commit undoing changes
-* Can be used on merges too!
-* Allows to document an undo
+Alernatives: `git revert` which allows to document an undo.
diff --git a/day2/02_Integrations/01_Intro.md b/day2/02_Integrations/01_Intro.md