diff --git a/Lerntagebuch.md b/Lerntagebuch.md
index ab3179c..5b7c539 100644
--- a/Lerntagebuch.md
+++ b/Lerntagebuch.md
@@ -280,5 +280,120 @@
     ### Mitteilung an die Dozierenden
 
         keine
+        
+## SU_05
+        
+        ### Automatisiertes Zusammenführen Literaturempfehlungen
+        
+        ### Lernziele
+        
+            #### Gründe:    man kann nicht alles allein bewältigen wegen steigender Komplexität und Aufwand. Deadlines sehr streng
+                            mehrere Entwickler
+                            Zusammenführen der Einzelleistungen
+                            Aufwand ()
+                            Formatierung des Quelltextes ist ein Problem (führt zu Konflikten beim Zusammenführen, kreativität hält nicht an Konvetionen)
+                            technische Konflikte (z.B. zwei Entwickler müssen eine Stelle ändern)
+                            persönliche Konflikte (gewöhnliche Gründe)
+                            
+            #### Vorteile:  automatisierte Prozesse verringern den Aufwand was auch Zeit einspart
+                            formale Prozesse verringern Konfliktpotential 
+                            Vorstufe für Continous Delivery (wenn nur noch automatische Prozesse ablaufen)
+                            
+            #### Entwicklungsprozess:   Code schreiben
+                                        Abhängigkeitsverwaltung (Bibliotheken etc.). Bereitstellung zu Laufzeit
+                                        Veröffentlichug des Codes
+                                        Integration (Zusammenfügen zum Gesamtsoftware)
+                                        build-Prozess (erstellen des Zielformats der Software aus Queltext)
+                                            compile 
+                                            test (automatisiertes Testen)
+                                        Bereitstellung (Erzeugung eine exe oder zip, Dateiform; Deliverable in Repository bereitzustellen)
+            
+            #### Abhängigkeitsverwaltung:   manche Teile kommen von außerhalb, alles was nicht aus dem Quellcode kommt ist Abhängigkeit
+                                            nicht im SCM eingecheckt 
+                                            zentrale Bereitstellung (in der Organisation, JVM öffentliche Repositories, kann auch lokal erstellt werden)
+                                            Zugriff auf einzelne Versionen (zeitgemäs, sonst konflikte)
+                                            
+            #### Versionierung: MAJOR inkompatible Änderungen (Änderungen am Quellcode)
+                                MINOR zusätliche Features
+                                Programmteil bleibt
+                                abwärtskompatibel
+                                PATCH Fehlerbehebungen
+                                Programmteil bleibt
+                                abwärtskompatibel
+                                LABEL spezifische Build-Kennzeichnung
+                                
+            #### SCM            Sicherung für einzelne Entwickler
+                                zentrale Verfügbarmachung
+                                zusammen führen parallel geäderter Dateine
+                                parallele Entwicklung verschiedener Features
+                                Zugriff auf dedizierte Stände
+                                branches
+                                
+            #### Build Prozess: Abhängigkeiten organisieren
+                                Übersetzen
+                                ausführung automatisierten Tests
+                                Liefer Artefakte erzeugen
+                                Deployment (das Lieferartefakt wird ausgegeben)
+                                
+            #### Tools:         make (c~, gnu~)i/ceedling
+                                    vorwiegend C/C++
+                                    keine Abhängigkeitsverwaltung
+                                maven/gradle
+                                    vorwiegend Java
+                                npm
+                                    JS/TS
+                                    
+            #### Integration:   Wir haben Server das Integration übernimmt
+                                SCM überwachen
+                                Änderungen zusammenführen
+                                build Prozess starten (befor Abhängigkeiten auflösen)
+                                    compilieren
+                                    Lieferartefakt erstellen
+                                    """" ausliefern
+                                Ergebnisse berichten ob es funftionnirete oder nicht
+                                
+            #### Probleme:      kein menschlicher Eigriff
+                                compilirbar != ausführbar
+                                CI soll immer lieferbaren Stand bereit halten
+                                Programm muss im CI Prozess ausgeführt werden
+                                
+            #### Automatisierte Tests:  führen Programm aus
+                                        dokumentieren gewünschtes Vergalten
+                                        sind wiederholbar
+                                        erkennen Laufzeitfehler (außer Unittests)
+                                        Ausführungszeit von Atbeitszeit entkoppelt (da wo keiner arbeiten will)
+                                
+            #### Grenzen:       finden nur Abweichungen von gewünschten/erwartetem Verhalten
+                                """""" keine neue fachlichen Fehler
+                                
+            #### Vorgehensmodelle:  gemeinsame remote repository
+                                    privater fork
+                                    
+            #### remote repository: alle arbeiten gegen RR
+                                    jeder hat Zugriff
+                                    einfache Synchronisation
+                                    gepushte Zwischenstände sind für alle sichtbar
+                                    
+            #### privater fork:     es gibt ein zentrales RR (= master)
+                                    jeder Entwickler hat ein separates RR (= fork)
+                                    jedes LR hat 2 RR
+                                        origin -> master, nur lesend
+                                        upstream -> privater fork, Schreiberechte
+                                    Änderungen werden per Pull Request aus dem fork in maser repository übernommen
+                                    
+        ### Erkenntnis
+
+            #### In der Praxisunterricht haben wir die erworbene Kenntnisse über remote repositories in das Praxis umgesetzt und Umgang damit trainiert.
+
+        ### Wiederholung
+
+            #### Zur Wiederholung haben wir den Umgang mit local repositories geübt. Die nächste Aufgabe war so aufgebaut, dass es ohne vorkenntnisse über lokal repositories nicht möglich war, diese zu bewältigen.
+        ### Kritik
+
+            #### keine
+
+        ### Mitteilung an die Dozierenen
+
+            #### keine