Erste Schritte¶
Hauptkomponenten¶
Bei der Arbeit mit Odoo.sh ist es wichtig, die Hauptkomponenten zu verstehen:
Obwohl sie alle miteinander verbunden sind, spielt jede einzelne eine eigene Rolle bei der Entwicklung und Bereitstellung von Odoo-Apps. Zusammen bilden sie eine zusammenhängende Pipeline von der Code-Entwicklung bis zum Einsatz im Geschäftsalltag.
Github-Repository¶
Ein GitHub-Repository ist wie ein Ordner auf Ihrem Computer, der alle Dateien und Ordner für ein bestimmtes Projekt enthält. Der Unterschied besteht darin, dass es auf GitHub gespeichert ist und von mehreren Personen auf verschiedenen Computern aufgerufen und bearbeitet werden kann.
Mit anderen Worten: Ein GitHub-Repository ist ein Ort, an dem Sie die Dateien Ihres Projekts speichern und mit anderen teilen können, damit diese mit Ihnen zusammenarbeiten, Änderungen vornehmen und zu Ihrem Projekt beitragen können. Es erfasst außerdem alle Änderungen an Ihrem Projekt im Laufe der Zeit, sodass Sie bei Bedarf problemlos zu einer früheren Version zurückkehren können.
Darüber hinaus bietet GitHub viele Funktionen, die Sie bei der Verwaltung Ihres Projekts unterstützen, wie z. B. Issue-Tracking, Pull-Requests und Code-Reviews. Es ist ein leistungsstarkes Werkzeug zur Verwaltung von und Zusammenarbeit an Softwareprojekten und wird von Entwicklern weltweit genutzt: ein versionskontrollierter Bereich, in dem der Quellcode der Odoo-Anwendungen gespeichert wird. Er erfasst jede Änderung, unterstützt die Zusammenarbeit und kann entweder öffentlich oder privat sein.
Odoo.sh-Projekt¶
Ein Odoo.sh-Projekt ist eine Platform as a Service (PaaS), die in GitHub integriert ist und eine optimierte Entwicklung, Tests und Bereitstellung von Odoo-Anwendungen ermöglicht. Es umfasst Tools wie automatisierte Backups, Staging-Umgebungen und Continuous-Integration-Pipelines.
Odoo-Datenbank¶
Eine Odoo-Datenbank speichert alle operativen Daten, die von Odoo-Anwendungen verwendet und erzeugt werden, wie z. B. Geschäftsdatensätze, Konfigurationen und Benutzerdaten.
Benutzertypen¶
Odoo.sh umfasst verschiedene Arten von Benutzern, von denen jeder eine spezifische Rolle im Projektlebenszyklus einnimmt:
GitHub-Benutzer: Entwickler mit Zugriff auf das mit dem Odoo.sh-Projekt verknüpfte GitHub-Repository. Der Zugriff auf das Repository macht jemanden nicht automatisch zu einem Mitwirkenden am Odoo.sh-Projekt.
Odoo.sh-Mitwirkende: Personen, die das Odoo.sh-Projekt verwalten. Jeder Mitwirkende muss mit einem GitHub-Benutzer verknüpft sein. Mitwirkende sind jedoch nicht dasselbe wie Datenbankbenutzer.
Datenbankbenutzer: Endbenutzer der bereitgestellten Odoo-Datenbank. Sie interagieren mit dem Produktivsystem, sind jedoch nicht an der Entwicklung oder am Projektmanagement beteiligt.
Technische Konzepte¶
Bei der Arbeit mit Odoo.sh ist es außerdem wichtig, mehrere technische Konzepte zu verstehen:
Ein Repository forken¶
Ein Repository auf GitHub zu forken bedeutet, dass Sie eine Kopie des Repositorys einer anderen Person in Ihrem eigenen Konto erstellen. So können Sie Änderungen am Repository vornehmen, ohne die Originalversion zu beeinflussen.
Wenn Sie ein Repository forken, erstellen Sie Ihre eigene Kopie des Repositorys, einschließlich aller Dateien und Ordner des Original-Repositorys. Anschließend können Sie Änderungen an den Dateien in Ihrer Kopie des Repositorys vornehmen und diese committen, genau wie bei jedem anderen Repository.
Der Vorteil des Forkens eines Repositorys besteht darin, dass Sie Änderungen am Code vornehmen können, ohne die Originalversion zu beeinflussen. Dies ist nützlich, wenn Sie mit neuen Funktionen experimentieren oder Fehler im Code einer anderen Person beheben möchten. Sie können das geforkte Repository auch als Ausgangspunkt für Ihr Projekt verwenden und bei Bedarf Änderungen vornehmen.
Sobald Sie Änderungen am geforkten Repository vorgenommen haben, können Sie einen Pull-Request an den Eigentümer des ursprünglichen Repositorys stellen und ihn bitten, Ihre Änderungen in sein Repository zu übernehmen. Dies ist ein gängiger Ansatz bei Open-Source-Projekten, um Beiträge anderer Entwickler zu akzeptieren. Es kann eine gute Möglichkeit sein, sich in der Community zu engagieren und Ihre Programmierkenntnisse zu verbessern.
Einen Commit pushen¶
Wenn Sie Änderungen an einer oder mehreren Dateien in einem Git-Repository auf Ihrem lokalen Computer vornehmen, gelten diese Änderungen als nicht committet. Mit anderen Worten: Git weiß, dass Änderungen vorgenommen wurden, aber sie wurden noch nicht offiziell gespeichert oder erfasst.
Um diese Änderungen zu speichern und dem Git-Repository hinzuzufügen, müssen Sie einen Commit erstellen. Ein Commit ist eine Momentaufnahme der Änderungen, die Sie zu einem bestimmten Zeitpunkt an den Dateien vorgenommen haben. Er erfasst, welche Änderungen vorgenommen wurden, von wem und wann.
Sobald Sie einen Commit erstellt haben, können Sie ihn zu einem Remote-Repository pushen, z. B. einem auf GitHub gehosteten. Einen Commit zu pushen bedeutet, die im Commit vorgenommenen Änderungen von Ihrem lokalen Repository an das Remote-Repository zu senden, damit andere sie sehen und nutzen können.
Zusammenfassend bedeutet das Pushen eines Commits, dass Sie die Änderungen, die Sie an den Dateien in Ihrem Git-Repository vorgenommen haben, von Ihrem lokalen Computer an ein Remote-Repository senden. So können Sie Ihre Änderungen mit anderen teilen und gemeinsam an einem Projekt arbeiten.
Einen Branch zusammenführen¶
Beim Zusammenführen (Merge) eines Branches in einen anderen werden die in einem Branch vorgenommenen Änderungen mit dem anderen kombiniert. Angenommen, Sie haben einen neuen Branch namens „feature-branch“ erstellt, um an einer neuen Funktion für Ihr Projekt zu arbeiten. Sobald Sie die Änderungen an diesem Branch abgeschlossen haben, können Sie diese Änderungen wieder in den Hauptbranch (oft „master“ oder „main“ genannt) zusammenführen.
Beim Zusammenführen eines Branches untersucht Git die Änderungen in beiden Branches und versucht, sie zu kombinieren. Gibt es Konflikte zwischen den in den beiden Branches vorgenommenen Änderungen, fordert Git Sie auf, diese zu lösen, bevor der Merge (codeseitig) abgeschlossen wird.