1. 2025-09-16
-
Memory Types: Stack/Heap
-
Value Type/Reference Type
-
Call by Value/Call by Reference
-
Distributed vs centralized version control
2. 2025-09-23
Testtermine:
-
2025-11-25 2025-12-02: 1. Test
-
2026-01-13: 2. Test
-
2026-04-21: 3. Test
-
2026-06-09: 4. Test
2.2. Einführung git
Fragen:
-
Was ist ein VCS?
-
Welche Probleme lösen VCS?
-
Unterschiede zwischen git und VCS wie zB SVN? (verteiltes vs zentrales VCS)
-
git - clients
-
git - workflow
-
Unterschied zwischen git und GitHub/gitlab/bitbucket/…?
-
Wie erstellt man ein lokales Repository?
-
Was ist ein Repository?
-
Unterschied zwischem
rmundgit rm? -
Was ist der Unterschied zwischen
git commitundgit push?
5. 2025-10-xx
5.1. Branching
5.1.1. Types of Branches
-
Feature Branch
-
Bugfix Branch
-
Hotfix Branch (wie Bugfix nur dringender)
-
Main Branch (Release Branch)
Main Branch wurde früher Master Branch genannt
-
Develop Branch
5.1.2. Branching-Strategies
No-Flow
GitHub Flow
-
Vereinfachte Braching-Strategie: GitHub Flow (FH-Bielefeld)
Figure 3. GitHub-Flow in Programster’s Blog-
Fazit:
-
-
Git-Flow Workflow: Es gibt 2 Haupt-Branches (main, develop) und mehrere Neben-Branches (feature, release, hotfix)
-
GitHub Flow: Es gibt nur einen Haupt-Branch (main) und mehrere Neben-Branches (feature, hotfix)
6. 2025-11-05
6.1. Forks and Pull Requests
In case somebody wants to contribute to a repo (owned by another person or organization) a fork of the original repo has to be done. The contributor can now change the forked repo without any limitations. When the contributor to get their changes back into the original repo they do a pull request, i.e., the contributor asks the owner to merge the changes back to the original repo.
A fork of a repo can be seen as a smart copy of the original repository. Smart in this sense that the fork has a "backlink" to the original repo and is aware if the original has changed. As a contributor be aware if you ask for a pull request to have your fork synchronized with the original before creating a merge request.
6.2. Exercises
Work in pairs (called Student A and student B in the sequel) and accomplish the following tasks.
6.2.1. Simple Pull Request
-
A creates a repository with one text file
Readme.md. -
B forks it and clones it
-
B makes some changes to
Readme.mdcommits them and pushes them -
B creates a pull request to A to get the changes back to the original
Play around with the GitHub UI to get used to it. Reflect the different directions when to compare the pulled changes. Look closely on the arrows in the UI.
6.2.2. Sync A Given Fork
-
A does some changes to
Readme.md`commits and pushes -
B reloads their fork to get the info that the original has changed
-
B syncs the changes
Again try the different scenarios GitHub offers (direct syncing, comparing) and get acquainted to the UI and functionality.
6.2.3. Create a Pull Request from a Non-Synced Fork
-
A changes their repo and B reloads but does not sync!
-
B changes their repo (same file and line as A) and creates a pull request
See what happens. How to deal with merge conflicts? How to avoid these?
6.2.4. Pull Requests from a Non-Synced Fork But Using a Branch
-
A changes their repo and B reloads but does not sync!
-
B creates a new branch, changes the same file and line as A and creates a pull request
Look again what’s happening? Prepare for a discussion next week about how to deal best with pull requests and especially which discipline to establish to avoid pain.
8. 2025-11-19
8.1. Merging vs. Rebasing
8.1.2. Warum Rebasing?
-
Fazit:
-
Beim Rebasing werden die Commits des Branches in die Historie des Ziel-Branches eingefügt, als ob sie direkt dort erstellt worden wären. Dies führt zu einer geradlinigeren und saubereren Historie, kann jedoch die ursprüngliche Kontextinformation der Commits verändern.
-
Beim Merge hingegen bleibt die ursprüngliche Historie erhalten, was zu einer komplexeren Struktur führen kann, aber den Kontext bewahrt. Branches werden oft nach dem Merge gelöscht, um die Repository-Historie übersichtlich zu halten.
-
8.2. Exercises
Work in teams of two students, accomplish the tasks given below and document each step in an adoc or md file. Grading will be done by taking a sample of your documentations. We will especially check the clarity and understandability of your documentation. Think of your document that it could serve as an explanation for your younger sibling (or any other younger relative you have and like) to understand merging and rebasing by reading the documentation of the following two tasks.
8.2.1. Merging
-
Create a repository, add a file
onMain.mdand commit -
Create a branch
a-feature, check it out, create a fileonBranch.mdand commit -
Add some more lines to
onBranch.mdand commit -
View and document the history
-
Switch back to main branch and view and document the history as well as the content of your repository.
-
Reflect and document: are there differences between the two histories and contents and why?
-
Add some more lines to
onMain.mdand commit -
Repeat the last step a few times (at least twice)
-
Document the history again
-
Switch back to the feature branch
-
Merge the main branch into the feature branch
-
Document the history of the feature branch
8.2.2. Rebasing
Repeat the steps given in the last exercise but instead of merging the main branch into the feature branch rebase the feature branch on the last commit of the main branch. Of course, you need not document the histories etc. what you already did in the first example.
BUT document the history of the feature branch after rebasing. There should be a difference. Analyse and document it clearly.
9. 2025-12-03
Work on the exercises given on November 19. Keep the required documentation of your work. Maybe we need it to tie break unclear grading cases.
10. 2025-12-10
10.1. Forking vs. Templating
GitHub allows two ways to create a new repository based on the content of another:
-
Fork
-
Create from Templates