|
|
|
@ -478,7 +478,58 @@ Ein Singleton ist ein Objekt einer Klasse welches genau einmal zur Runtime läuf |
|
|
|
- Änderungen durch Baumstruktur gut verfolgbar |
|
|
|
|
|
|
|
- Arten von SCM Systemen |
|
|
|
- |
|
|
|
- zentralisiert |
|
|
|
- Änderungen werden beim Server gespeichert/zentrale Instanz nötig |
|
|
|
- jeder Entwickler kann immer alles sehen (mit aktuellen Änderungen) |
|
|
|
- gleichzeitiges Ändern der selben Datei nicht möglich |
|
|
|
- wird von System verhindert um Mergeprobleme zu verhindern |
|
|
|
- zentraler Server hat Backup Strategie und nahe zu endlich Speicherplat |
|
|
|
- IT-Abteilung kümmert sich um Instandhaltung |
|
|
|
- nahe zu unendlich viele Personen können gleichzeitig am Projekt arbeiten |
|
|
|
- Serverkomponente auf jedem Rechner nötig |
|
|
|
- "locking" verhindert gleichzeitiges Arbeiten an der selben Datei |
|
|
|
- gemerged Branches sind für alle sichtbar |
|
|
|
- soll aber eventuell nicht für alle sichtbar sein, da es sich nur um eine vorläufige Testversion handeln könnte die noch Bugs enthält |
|
|
|
- Offlinearbeit nicht möglich |
|
|
|
|
|
|
|
- dezentral/verteilte Systeme |
|
|
|
- keine zentrale Komponente |
|
|
|
- jeder Entwickler hat seine eigene Kopie |
|
|
|
- zentrale Instanz (oder mehrere) möglich aber nicht __nötig__! |
|
|
|
- arbeiten ohne Onlineverbindung möglich |
|
|
|
- Onlineverbindung für Synchronisation nötig |
|
|
|
- impliziete Backups durch Arbeitskopie jedes Entwicklers |
|
|
|
- eigene Testversion/_Experimente" bleiben privat |
|
|
|
- immer _out of sync_ |
|
|
|
- lokale Änderungen werden erst nach einem Push/Fetch synchronisiert |
|
|
|
- kein Schutz vor Änderungen in der selben Zeile |
|
|
|
- hohe Wahrscheinlichkeit für Mergekonflikt |
|
|
|
|
|
|
|
- Git im Speziellen (und Umgang mit Git) |
|
|
|
- entwickelt vom Linux Erfinder |
|
|
|
- Linus Torvalds |
|
|
|
- Änderungen/Commits |
|
|
|
- nicht dateibasiert, sondern (Datei-) übergreifend |
|
|
|
- nicht eine Datei wird "gelockt" wie bei zentralisierten Systemen |
|
|
|
- sind eindeutig benannt |
|
|
|
- keine Verwechselungsgefahr |
|
|
|
- jede Änderung hat einen SHA-Key |
|
|
|
- ermöglicht kleine Änderungen |
|
|
|
- daruch kleine Chance auf Mergeconflicts und einfacher dokumentierbar |
|
|
|
- Git kann kleiner Konflikte selber lösen |
|
|
|
- kann Logik _nachvollziehen_ |
|
|
|
- daruch _cleane_ Commits bei denen alle automatisierte Tests durchlaufen |
|
|
|
- ermöglicht _cherrypicking_ von Merges |
|
|
|
- nur einzelne Änderungen werden commited |
|
|
|
- ermöglicht Suche nach bestimmten Commits durch Commitheaders |
|
|
|
- besitzt Branches/Zweige |
|
|
|
- Kennzeichnung eines Commits durch Branches |
|
|
|
- besitzt eine Staging Area |
|
|
|
- Testbereich für Änderungen |
|
|
|
- bleibt erhalten bei Zweigwechsel |
|
|
|
- _sammelt_ Änderungen |
|
|
|
- werden bei Bedarf mit einem Commit gepusht |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fdai7783
1 year ago