Unterstützung bei der Umstellung auf GIT

[GTB]

Hallo Community,

es wurde hier im Forum schon mehrfach diskutiert und nachgefragt.
Wir arbeiten aktuell noch mit Subversion (SVN), sind aber gewillt umzusteigen auf einen eigenen GIT Server.

Dazu haben wir auch schon bei dem ein oder anderen nachgefragt ob er uns dabei unterstützen kann, doch es ist bisher immer im Sand verlaufen.

Wir würden hier nochmals einen Versuch unternehmen.

Unser komplettes Konstrukt von der täglichen Arbeit, über Tickets und bis hin zur Veröffentlichung einer neuen Version ist alles auf SVN abgestimmt. Das muss dann alles umgebaut werden auf GIT.  Gerade bei der Übernahme der gesamten Tickets kann uns unser Hoster unterstützen.

Was wir benötigen sind Einweisungen und Optimierungen in Abläufen für einfache Commits, Pullrequests, etc.
Mein Wissen in Sachen GIT geht gegen Null.

Wer von euch kann uns dabei unterstützen und wie kann diese Unterstützung aussehen ?

Bitte meldet euch einfach über das Kontaktformular wie ihr uns unterstützen könnt.

Wir freuen uns auf eure Nachrichten.

Gruss Gerhard

Linkback: https://www.modified-shop.org/forum/index.php?topic=43120.0

[RobinTheHood]

Allgemein
In Git wird intensiv mit Branches und Merges gearbeitet, da diese effizient funktionieren und nur begrenzten Speicherplatz beanspruchen. In Git gibt es verschiedene Arbeitsstrategien wie:

- Die Gitflow Strategie
- Die GitHub Flow Strategie
- Die GitLab Flow Strategie
- Die Feature-Branch Strategie
- Die Release-Branch Strategie
- etc.

Eine typische Git-Arbeitsstrategie könnte wie folgt aussehen. Es ist eine Release-Branch Strategie:

Der Haupt-Branch wird main genannt, obwohl es prinzipiell möglich ist, ihn nach eigenen Vorstellungen zu benennen. Früher wurde dieser oft master genannt, jedoch ist diese Bezeichnung seit einigen Jahren veraltet. Die gängige Konvention ist main. In SVN wird dieser Haupt-Branch als trunk bezeichnet.

Das Hauptziel besteht darin, den Haupt-Branch main möglichst fehlerfrei zu halten. Obwohl dies in der Praxis nicht immer erreichbar ist, ist es dennoch das angestrebte Ziel. Mit "fehlerfrei" ist gemeint, dass zu jedem Zeitpunkt der aktuelle main-Branch ausgecheckt werden kann und die Version von modified funktioniert.

Tägliche Arbeit
Wenn ein Team-Entwickler ein neues Feature implementieren möchte, erstellt er einen neuen Branch vom Haupt-Branch main. Dieser Branch wird oft nach dem Schema feat/my-new-feature benannt, wobei die Verwendung von feat/ gängige Praxis ist. Dies erleichtert die Übersichtlichkeit, da einige Tools feat/ als ausklappbaren Ordner anzeigen.

Im Branch feat/my-new-feature kann der Entwickler nun ungestört am neuen Feature arbeiten. Währenddessen können im main-Branch andere Änderungen vorgenommen worden sein, die eventuell nicht mehr mit dem Code im feat/my-new-feature-Branch kompatibel sind. Sobald das neue Feature abgeschlossen ist, werden die Änderungen aus dem main-Branch erneut in den feat/my-new-feature-Branch überführt, was als Merge bezeichnet wird. In diesem Fall werden die Änderungen aus main in feat/my-new-feature integriert. Anschließend erfolgt eine erneute Überprüfung, ob das Feature immer noch einwandfrei funktioniert. Wenn nicht, sind weitere Anpassungen erforderlich. Wenn alles funktioniert, wird der feat/my-new-feature-Branch in den main-Branch gemerged. Danach kann der feat/my-new-feature-Branch gelöscht werden, da er nicht mehr benötigt wird.

Bei der Bearbeitung von Bugfixes erfolgt der Prozess ähnlich, wobei das Präfix fix/ anstelle von feat/ verwendet wird.

Das Repository kann zu einem beliebigen Zeitpunkt wie folgt aussehen:

- main
- feat/my-new-feature-1
- feat/my-new-feature-2
- feat/new-shipping-modul
- fix/show-missing-button
- fix/typo-in-checkout
- release/2.0.1
- release/2.0.2

Release einer neuen Version
Wenn der main-Branch soweit entwickelt ist, dass eine neue Version von modified veröffentlicht werden soll, befindet man sich im sogenannten "Endgame".

Kurz vor der Veröffentlichung einer neuen Version von modified wird ein Release-Branch erstellt, der beispielsweise release/2.0.1 genannt wird. Hier werden alle Version von 2.0.1.x verwaltet. Dieser Branch dient dazu, alle Änderungen und Bugfixes für diese spezielle Version zu organisieren.

Alle kritischen Probleme sollten nun sowohl im Hauptzweig main als auch im release/2.0.1-Branch behoben werden.

Wenn keine weiteren kritischen Probleme mehr vorhanden sind, wird ein Release-Tag mit der Versionsnummer erstellt, beispielsweise 2.0.1.0. Dies markiert offiziell die Veröffentlichung der Version, die aus diesem Tag ausgeliefert wird.

Schwere Fehler werden im release/2.0.1-Branch bearbeitet und behoben. In diesem Branch werden die Versionen dann wie folgt getaggt:

- 2.0.1.1
- 2.0.1.2
- 2.0.1.3
- usw.

Die Entwicklung an Versionen wie 2.0.2.x erfolgt parallel oder nach Abschluss des "Endgame" im main-Branch. Bis es das nächste Endgame mit Branch release/2.0.2 gibt.

Pull Requests
Pull Requests (bei GitHub) oder Merge Requests (bei GitLab) sind Organisationsstrukturen, die bei GitHub und GitLab verwendet werden. Vereinfacht ausgedrückt handelt es sich um Anfragen von anderen Benutzern (nicht Team Mitgliedern), die keinen Schreibzugriff auf das Repository haben. Wenn ein Benutzer, z. B. User A, einen Branch namens feat/my-new-feature-user-a vom main-Branch erstellt hat, kann er über die Plattform eine Anfrage stellen, dass ein Administrator (Teammitglied) den fertigen Branch feat/my-new-feature-user-a in den main-Branch integriert. GitHub und GitLab bieten zusätzliche Funktionen, mit denen Admins und Benutzer vor der Zusammenführung (Merge) Änderungen leicht besprechen können, um etwaige Anpassungen vorzunehmen, bevor der Administrator auf die Schaltfläche "MERGE" klickt oder die Pull Request bzw. Merge Request ablehnt.

Mit besten Grüßen
Robin

PS: Es gibt ein super online "Game", das sich im Browser spielen lässt, um das Branchen und Mergen mit Git zu lernen und zu üben: https://learngitbranching.js.org/?locale=de_DE

[Q]

Das Ticketing läuft dann bei GitHub über Issues und in GitLab über Incidents?

[RobinTheHood]

Das Ticketing-System auf beiden Plattformen, GitHub und GitLab, basiert auf dem Konzept von "Issues". Mit GitLab Incidents habe ich persönlich noch nie gearbeitet.

GitHub und GitLab Tickets weisen eine hohe Ähnlichkeit in ihrer Struktur auf. Beide ermöglichen es den Benutzern, Issues zu erstellen, zu verwalten und zu verfolgen. Diese Issues dienen dazu, Probleme, Aufgaben oder Diskussionen im Zusammenhang mit einem Projekt zu dokumentieren und zu organisieren. Sie würden die Tickets aus dem Trac ersetzen und können noch ein bisschen mehr.

Einer der Schlüsselvorteile beider Plattformen ist die Integration von Issues mit Pull-Requests (GitHub) bzw. Merge-Requests (GitLab). Auf diese Weise können Entwickler ziemlich leicht neue Branches erstellen, um an den jeweiligen Problemen zu arbeiten und dann diese Branches in die Hauptbranch main integrieren.

Zusätzlich bieten sowohl GitHub als auch GitLab, wie auch das Trac die Möglichkeit, Issues mit vordefinierten Labels zu versehen. Diese Labels dienen dazu, Issues zu kategorisieren und zu organisieren.  Z. B.: Labels wie "Bug" für Fehlerberichte, "Feature" für neue Funktionen, "Good First Issue" für Anfängerfreundliche Aufgaben und "Question" für Fragen oder Diskussionen. Dies macht es einfacher, Issues zu filtern und Prioritäten zu setzen.

[RobinTheHood]

Aktuell werden im Trac-Projektplan Meilensteine verwendet und Tickets werden diesen Meilensteinen zugeordnet. Ähnliche Vorgehensweisen sind auch in GitHub und GitLab üblich, wo Meilensteine erstellt werden können, um den Fortschritt eines Projekts prozentual zu veranschaulichen und zu organisieren.

Meine Empfehlung wäre folgende: Einen Meilenstein einzurichten, der als "Backlog" bezeichnet wird und niemals abgeschlossen wird. In diesem Backlog werden alle neu eingehenden Anfragen und Aufgaben gesammelt. Anschließend sollte ein Meilenstein für den nächsten geplanten Release erstellt werden, zum Beispiel "2.0.1.0". Die Team-Entwickler können dann entscheiden, welche Anfragen und Aufgaben aus dem Backlog dem Meilenstein "2.0.1.0" zugeordnet werden sollen.

Persönlich würde ich davon abraten, zu viele Releases oder Meilensteine in die Zukunft zu planen. Oftmals sind die folgenden drei Meilensteine als Beispiel ausreichend:

• Backlog: Hier werden neue Aufgaben und Anfragen gesammelt.
• 2.0.1.0: (Release der Minor-Version): Dieser Meilenstein kennzeichnet die nächste geplante Version des Projekts.
• 2.0.1.1: (Release von Fehlerbehebungen nach Bedarf): Dieser Meilenstein kann verwendet werden, um dringende Fehlerbehebungen und kleinere Updates zu organisieren.

Diese vereinfachte Struktur bietet einen klaren Überblick über die anstehenden Aufgaben und hilft dabei, den Fokus auf die nächste Version des Projekts zu legen.

[snocer]

Hallo GTB,

eigener Git Server auf einem Linux Server oder auf einem Windows Server? Geht auf beidem.
GitHub ist eine fertige gehostet Umgebung mit monatlichen Kosten, Enterprise ca. 20 EUR pro Monat.
Eigener Server kostet in dem Fall nichts wen auf einem bereits bestehenden Server Git gehostet wird.
Da ihr ja bereits SVN einsetzt, gehe ich mal von einem Linux / Apache System aus.
Installation mit Gitea etwas schlanker als GitLabs.

cu snocer

[RobinTheHood]

Hallo,

in Bezug auf die Umstellung von SVN auf Git und die damit verbundenen Überlegungen zur Zielsetzung und den Auswirkungen auf die Zusammenarbeit im Team und externen Entwicklern, möchte ich folgendes festhalten:

Es stellt sich die Frage der definierten Ziele bei der Umwandlung von SVN zu Git. Die schlichte Umstellung ohne eine klare Zielsetzung erscheint wenig sinnvoll. Es sollte stets ein konkreter Zweck damit verfolgt werden, sei es die Verbesserung der Versionskontrolle, die Einführung von Feature-Branches oder die Erleichterung der Teamzusammenarbeit mit externen Entwicklern. Ohne eine klare Zielsetzung könnte diese Umstellung unnötigen Aufwand verursachen und die Entwicklungsprozesse nicht verbessern.

Git ist in erster Linie ein Versionskontrollsystem wie SVN und allein nicht in der Lage, die Kollaboration und Zusammenarbeit effizient zu gestalten. Die Umstellung auf Git allein verbessert daher nicht zwangsläufig die Zusammenarbeit. Git bietet zwar branch-basierte Entwicklung, doch es fehlen Funktionen wie Code-Reviews, Issue-Tracking und ein übersichtliches Dashboard, die in Kollaborationswerkzeugen wie GitHub oder GitLab standardmäßig integriert sind.

Die Verwaltung von Pull-Requests und die Kommunikation über Code-Änderungen in einer reinen Git-Umgebung mit Nicht-Teammitgliedern sind zwar etwas leichter als mit SVN aber immer noch zeitaufwendig und fehleranfällig. Hierbei sind manuelle Prozesse erforderlich, um Änderungen zu überprüfen, Feedback zu geben und den Entwicklungsfortschritt zu koordinieren. Dieser zusätzliche Aufwand kann die Effizienz des Entwicklungsteams in einer reinen Git-Umgebung beeinträchtigen.

Kollaborationsplattformen wie GitHub und GitLab wurden entwickelt, um die Herausforderungen in Bezug auf die Kollaboration zu lösen. Diese Plattformen bieten Funktionen wie Pull-Requests, Code-Reviews, Issue-Verwaltung und Kommunikation mit dem Team und externen Entwicklern, die die Produktivität und Effizienz bei der Zusammenarbeit in Softwareprojekten erheblich steigern. Ohne diese Tools wäre die reibungslose Zusammenarbeit in verteilten Teams erschwert.

Ähnlich wie bei der aktuellen Verwendung von Trac und SVN, bei der Trac auf SVN aufbaut, bauen GitHub und GitLab auf Git auf. In Bezug auf Gitea kann ich keine Erfahrungen teilen, da ich damit noch nicht gearbeitet habe.

Allgemein stellt sich die Frage, ob es sinnvoll ist, die Arbeit in einen eigenen Serverbetrieb zu investieren. Dies ist letztendlich eine Frage von Zeit und Kosten. Es ist zu überlegen, ob es wirtschaftlicher ist, Anbieter mit dieser Aufgabe zu beauftragen. Also GitHub oder GitLab als SaaS. Die Anzahl der Personen, die benötigt werden, um einen GitLab-Server zu administrieren, hängt von verschiedenen Faktoren ab, wie der Größe des Teams und der Komplexität des Projekts. Zudem stellt die Selbstverwaltung eine weitere Hürde dar, da Benutzer eigene Accounts anlegen müssen, anstatt bestehende GitHub- oder GitLab-Accounts zu verwenden. Es gibt jedoch Möglichkeiten, die Anmeldung über GitHub oder GitLab zu ermögliche so viel ich weiß, wenn dies entsprechend konfiguriert wird. Was das genaue Hosting von GitLab auf einem eigenen Server betrifft, fehlt mir spezifisches Wissen.

@snocer:
Unabhängig von GitHub oder GitLab. Da modified ein Open-Source-Projekt ist und vermutlich keine versteckten privaten Repositories benötigt, halte ich GitHub Free für Organisationen mit vollem Funktionsumfang zum Preis von 0,00 Euro pro Monat für vollkommen ausreichend. Gleiches gilt für GitLab und co.

Mit besten Grüßen
Robin

[vr]

Hallo Robin,

vielen Dank für Deine umfangreichen und detailierten Hinweise. Danke auch an snocer für den Input.

Ein Fazit scheint mir, dass es für uns sinnvoll wäre, eine github-Instanz zu nutzen, weil git alleine speziell bzgl Code-Beiträgen von außerhalb des teams zu aufwändig/fehleranfällig wäre. Es gibt einige Experten in der community, die aus unterschiedlichen Gründen nicht Teil des teams sein wollen, und deren Input könnten wir dadurch auch nutzen.

Die Differenzierung zwischen github und gitlab ist mir noch nicht klar, deswegen gehe ich zur Vereinfachung erstmal von github aus.

Was wären denn die Vorteile, wenn wir github selber hosten bzw über SaaS hosten lassen? Wenn wir github selber hosten, haben wir auch den Adminaufwand, das aktuell zu halten, hast Du da Erfahrungswerte, wie aufwändig das ist? trac/SVN konnten wir ja ohne Probleme selber hosten und administrieren. Ist github da wesentlich aufwändiger?

Wenn wir github SaaS hosten lassen, haben wir monatliche Kosten. Bietet das einen Vorteil gegenüber dem von Microsoft betriebenen weltweiten github-Portal? In irgendeiner Form mehr Kontrolle über Accounts, Code, Abläufe, Nutzungsrechte? Der Aspekt, dass User ihr (MS)github-Login nutzen können, ist glaube ich zu vernachlässigen, da modified nicht weltweit operiert oder weltweit Entwickler anspricht. Der Preis fürs Hosting durch MS wäre wohl wie bei allen "kostenlosen" cloudbasierten Diensten, dass wir mit Daten bezahlen.

Vielel Grüße, Volker

[RobinTheHood]

Hallo,

folgendes kann ich zu vr Fragen sagen.

1. Unterschiede der zwischen GitHub und GitLab
GitHub und GitLab sind zwei beliebte Plattformen für die Versionsverwaltung von Quellcode und die Zusammenarbeit an Softwareprojekten die auf Git aufbauen und ähnliche Features bieten. Hier einige unterschiede:

1.1. Hosting:
- GitHub: GitHub ist eine cloudbasierte Plattform. Sie bietet kostenlose und kostenpflichtige Optionen.
- GitLab: GitLab ist sowohl als cloudbasierte Plattform als auch als selbstgehostete Plattform.

1.2. Lizenzmodell:
- GitHub: GitHub bietet kostenfreie Repositories für Open-Source-Projekte und berechnet für private Repositorys Gebühren, wenn man bei privaten (nicht öffentlich sichtbare) Repositorys alle Funktionen haben möchte.
- GitLab: GitLab bietet eine "Core"-Version mit grundlegenden Funktionen kostenlos an und bietet auch eine "Enterprise"-Version mit erweiterten Funktionen und Support für kostenpflichtige Nutzer an.

1.3. Funktionen:
- Beide: Erweitern die Versionsverwaltung und Zusammenarbeit an Codeprojekten. Sie bietet Funktionen wie Issues, Pull- / Merge- Requests, Actions, integriertes CI/CD (Continuous Integration/Continuous Deployment), ein Wiki. Dies macht beide zu einer DevOps-Plattform, wobei bei DevOps GitLab etwas die Nase vorn hat, aber das ändert sich von Monat zu Monat.

1.4. Community:
- GitHub: GitHub hat eine große Entwickler-Community und bietet eine breite Palette von Integrationen und Erweiterungen, um die Zusammenarbeit und Automatisierung zu unterstützen.
- GitLab: GitLab verfügt ebenfalls über eine aktive Community und bietet viele Integrationen, insbesondere für DevOps und Continuous Integration.

1.5. Sicherheit:
- Beide Plattformen legen großen Wert auf Sicherheit und bieten Funktionen wie Authentifizierung, Zugriffskontrolle und Sicherheitsprüfungen. Bei GitHub können z. B. durch einen Bot automatisch Sicherheits relevante Fehler im quellcode aufgespürt werden.

Die Wahl zwischen GitHub und GitLab hängt von den spezifischen Anforderungen des Projekts und der Organisation ab. GitHub eignet sich gut für die Zusammenarbeit an Open-Source-Projekten, während GitLab eine umfassendere DevOps-Plattform für Unternehmen bietet.

2. Wieso ich für GitHub wäre
Wenn es nach meiner Meinung geht, gäbe es mehrere gute Gründe, warum es sinnvoller sein könnte, das modified Shop System öffentlich bei GitHub zu entwickeln, anstelle eine eigenen GitLab-Instanz auf einem eigenen Server zu verwenden:

2.1. Größere Entwickler-Community:
GitHub ist eine der größten Plattformen für Open-Source-Entwicklung. Durch die Veröffentlichung auf GitHub erhöht man die Sichtbarkeit des Projekts und zieht mehr Entwickler an, die dazu beitragen möchten. GitLab auf einer eigenen Instanz hat in der Regel eine kleine Benutzerbasis. Hier kenne ich das Gegenargument, dass modified ja von wenigen genutzt wird und das es nicht realistisch ist, dass man durch die große GitHub Community Entwickler erreicht. Das wäre aber für mich nur ein Argument, wenn man nicht das Ziel verfolgt, mit der Zeit wieder größer zu werden. Desto größer das Projekt, um so mehr profitiert man später davon, dass man sich auf GitHub befinden würde.

2.2. Unterstützung:
Durch die Zusammenarbeit mit der breiten GitHub-Community kann man wertvolles Feedback erhalten, Fehlerberichte und Pull Requests von deutlich mehr Entwicklern. Das führt zu einer besseren Fehlerbehebung und Weiterentwicklung des Systems.

2.3. Wartungskosten:
Wenn man GitLab auf einem eigenen Server betreibt, muss man die Infrastruktur und Wartungskosten selbst tragen. GitHub bietet einen gehosteten Dienst, der die Notwendigkeit für eigene Serverinfrastruktur eliminiert und für die Anforderungen die ich kenne für modified kostenlos wäre.

2.4. Zuverlässigkeit:
GitHub verfügt über eine hohe Verfügbarkeit und Zuverlässigkeit. Auf einer eigenen GitLab-Instanz wäre modified selbst für Sicherung und Wiederherstellung des Codes verantwortlich, was zu Ausfallzeiten führen kann.

2.5. CI/CD-Tools:
GitHub bietet integrierte Continuous Integration (CI) und Continuous Deployment (CD)-Tools, die die Entwicklung und Bereitstellung des Codes erleichtern und automatisieren kann. Bei einer eigenen GitLab-Instanz müsste man diese Tools wahrscheinlich selbst konfigurieren.

2.6. Integration mit anderen Tools:
GitHub bietet Integrationen mit einer Vielzahl von Tools und Diensten, einschließlich Projektmanagement-Tools, Code-Überprüfung und mehr. Dies erleichtert die Integration in bestehende Entwicklungs- und Workflow-Umgebungen.

2.7. Marketing:
GitHub würde eine Plattform für Marketing und Sichtbarkeit bieten. Das Projekt kann auf der GitHub-Plattform entdeckt werden, was dazu beitragen kann, mehr Benutzer und Mitwirkende anzuziehen. Mit jedem Entwickler der einen Pull-Request macht oder jedem Issue, das gemeldet wird, würde modified auf dem Account des Entwicklers an Sichtbarkeit gewinnen.

2.8. Dokumentation:
Für GitHub gibt es im Internet deutlich mehr Dokumentation und Tutorials, die den Einstieg einfacher machen.

3. GitHub in der modified Community
Hier aus der Community verwenden bereits einige aktive Modulentwickler GitHub. Ganz besonders ist das GitHub Account von Jay hervorzuheben. Wie man dort sehen kann, hat er sich bereits an mehreren großen OpenSource Projekten (Wordpress, VS-Code) beteiligt. In der modified Community möchte er nach meinem Kenntnisstand erst nicht Teammitglied werden müssen, um ebenfalls einen Beitrag leisten zu können.

Die folgende Liste an bekannten Personen aus dem Forum konnte ich auf die Schnelle finden, die bereits (erste) Erfahrungen mit GitHub haben:

Jay
https://github.com/grandeljay

RobinTheHood (ich)
https://github.com/RobinTheHood

Hetfield / MerZ IT-SerVice
https://github.com/hetfield74

Fishnet Services
https://github.com/shopbetreuung

TimoPaul
https://github.com/timopaul

Alkim Media
https://github.com/AlkimMedia

Karl1
https://github.com/KarlBogen

hpzeller
https://github.com/hpzeller

Gulliver72
Hat Pull-Request bei Karls bootstrap4 Modul gemacht
https://github.com/Gulliver72

Zudem habe ich noch einige weitere gefunden, bei denen ich aber nicht weiß, ob diese möchten, dass diese in der Liste mit auftauchen. Die oben gezeigten, haben ihre Accounts bereits mal im Forum oder wo anderes öffentlich gepostet.

So kann ich mir verschiedene Gründe vorstellen, warum Mitglieder der modified Shop Entwickler Community, die bereits einen GitHub-Account haben, möglicherweise ein Interesse daran haben könnten, dass die Entwicklung von modified auf GitHub und nicht auf einer anderen Plattform stattfindet.

3.1. Vertrautheit:
Die Entwickler sind bereits mehr oder weniger mit GitHub vertraut und nutzen es (regelmäßig) für Open-Source-Projekte. Wenn sie ihre Entwicklungsaktivitäten auf GitHub fortführen können, fühlen sie sich möglicherweise wohler und effizienter in ihrer Arbeit.

3.2. Integration:
Wenn die Entwickler bereits GitHub für andere Projekte nutzen, bietet die konsistente Verwendung der Plattform den Vorteil, dass sie ihre Arbeitsabläufe und Tools beibehalten können, an die sie bereits gewöhnt sind.

3.3. Bekanntheit:
GitHub ist eine der bekanntesten Plattformen für Open-Source-Entwicklung. Die Verwendung von GitHub kann dazu beitragen, die Bekanntheit von modified und die Sichtbarkeit der Entwicklungsarbeit zu steigern. Dies kann dazu führen, dass mehr Entwickler auf das Projekt aufmerksam werden und möglicherweise dazu beitragen.

3.4 Reputation:
Viele OpenSource Entwickler haben als Gegenleistung nur die Reputation, die sie durch einen Beitrag erwerben. Die Motivation ist sicherlich geringer, wenn man die Erbrachte Leistung hinter einer eigenen GitLab Instanz verstecken würde, als das der eigene Beitrag öffentlich auf GitHub zur Reputation beiträgt.

3.4. Migrationsaufwand:
Ein Wechsel von einer Plattform zur anderen erfordert Zeit und Ressourcen, um bestehende Repositories, Issues und Pull Requests zu migrieren. Wenn Entwickler bereits auf GitHub aktiv sind, kann die Verwendung von GitHub den Aufwand und die Unannehmlichkeiten einer Plattformmigration vermeiden.

Hier fließt viel meine eigene Meinung mit ein. Aber ich denke, Andere können gerne schreiben, wieso sie eine andere Plattformen bevorzugen würden. Vielleicht gibt es auch gute Gründe, eine andere Plattform zu verwenden, die ich bis jetzt noch nicht auf dem Schirm habe.

Mit besten Grüßen
Robin

[Karl1]

Hallo Zusammen,
ich nutze zwar GitHub, aber eigentlich nur als öffentlichen Datenspeicher.
Da ich ungern auf der Konsole arbeite, bin mir meist zu unsicher, nutze ich TortoiseGit (hier ein Screenshot vom Projekt "bootstrap4" auf meiner Festplatte).

[ Für Gäste sind keine Dateianhänge sichtbar ]

Auf Rechtsklick erscheint ein Kontextmenü, das mir mit den Befehlen behilflich ist.

Grundsätzliche Frage ist aus meiner Sicht, will man den Code zu jeder Zeit allgemein zugänglich machen?

Ich würde es begrüßen, man könnte Codeänderungen anhand der "Commits" früher erkennen, nachvollziehen und eventuelle Fehler bereits vor der Veröffentlichung einer neuen Version beheben.
Die Releaseabstände sind derzeit so groß (letztes Release vom Juli 2022), dass das Verfolgen von Änderungen quasi unmöglich ist. Jede neue Version ist für im Forum Helfende eine neue Wundertüte.

Große Open Source Projekte (Wordpress, Joomla usw.) sind bei GitHub, dann sollte das auch für "Modified" geeignet sein.

Gruß Karl

[Jay]

Moin,

Da ich ungern auf der Konsole arbeite, bin mir meist zu unsicher, nutze ich TortoiseGit (hier ein Screenshot vom Projekt "bootstrap4" auf meiner Festplatte).

Ist bei mir ähnlich. Persönlich gefällt mir GitHub Desktop gut. Es ist open source und funktioniert auch generell für git (es ist nicht auf GitHub Projekte beschränkt)

Grundsätzliche Frage ist aus meiner Sicht, will man den Code zu jeder Zeit allgemein zugänglich machen?

Ich finde es gibt da mehrere Gründe:

• Warum nicht?
• Es ermöglicht Modulentwickler ihre Module für die nächste Version vorzubereiten. Aktuell sollte man nie sofort nach einem modified release aktualisieren, da man den Modulentwicklern erst Zeit geben muss deren Module auf die neue Version anzupassen. Das finde ich ein bisschen schade.
• Man weiß auf welchem Stand die modified Entwickler arbeiten. Aktuell gibt es nur dev.modified-shop.org. Ich fände es praktischer wenn man direkt im code auch den neusten Stand hat damit es möglichst wenig Konflikte bei Pull Requests oder ähnlichem gibt

Ich würde es begrüßen, man könnte Codeänderungen anhand der "Commits" früher erkennen, nachvollziehen und eventuelle Fehler bereits vor der Veröffentlichung einer neuen Version beheben.
Die Releaseabstände sind derzeit so groß (letztes Release vom Juli 2022), dass das Verfolgen von Änderungen quasi unmöglich ist. Jede neue Version ist für im Forum Helfende eine neue Wundertüte.

Große Open Source Projekte (Wordpress, Joomla usw.) sind bei GitHub, dann sollte das auch für "Modified" geeignet sein.

Da stimme ich dir zu. Ich finde es auch absolut angebracht ein öffentliches Repository auf GitHub einzurichten. Es ist auch inzwischen "Standard" und öffnet einen riesigen Markt an potentiellen Entwicklern die beitragen können.

Zumal modified sich auch als Open Source bezeichnet, da finde ich dass der Quellcode auch "Open" sein darf. Wenn der nur privat einzusehen ist, finde ich das schon sehr suspekt für ein Open Source Projekt. Da wäre ich als User und/oder Entwickler eher Skeptisch gegenüber. Ich frage mich, was es denn zu verstecken gibt?

VG
Jay

[RobinTheHood]

Hallo,

als ich mit Git angefangen habe, habe ich ebenfalls nicht gern damit in der Konsole gearbeitet. Auch heute noch verwendet ich sehr gerne eine GUI für viele Aufgaben. Es gibt für Git sehr viele schöne kostenlose Tools mit denen man angenehm mit Git (inkl. GitHub, GitLab, bitbucket, etc.) arbeiten kann. Hier ist eine Liste von (aktuell) kostenlosen Git-Benutzeroberflächen (UI-Clients) für verschiedene Betriebssysteme:

GitHub Desktop (Windows, macOS)
GitHub Desktop ist ein offizieller Git-Client von GitHub und bietet eine benutzerfreundliche Oberfläche für Git-Repositories.
https://desktop.github.com

Sourcetree (Windows, macOS)
Sourcetree wird von Atlassian entwickelt und bietet eine intuitive Benutzeroberfläche für Git- und Mercurial-Repositories.
https://www.sourcetreeapp.com

GitKraken (Windows, macOS, Linux)
GitKraken ist eine visuell ansprechende Git-UI, die sowohl für Git als auch für GitHub optimiert ist. Es gibt eine kostenlose Version mit grundlegenden Funktionen.
https://www.gitkraken.com

GitExtensions (Windows)
GitExtensions ist eine Windows-spezifische Git-UI, die Git-Repository-Management und zahlreiche Funktionen für die Arbeit mit Git bietet.
https://gitextensions.github.io

SmartGit (Windows, macOS, Linux)
SmartGit ist ein umfassender Git-Client mit einer kostenlosen Version, die für den persönlichen Gebrauch oder kleine Teams geeignet ist.
https://www.syntevo.com/smartgit/

Git Cola (Windows, macOS, Linux)
Git Cola ist eine leichtgewichtige und Open-Source-GUI für Git. Sie bietet grundlegende Git-Funktionen und ist einfach zu bedienen.
https://git-cola.github.io

TortoiseGit (Windows)
TortoiseGit ist eine Windows-Explorer-Erweiterung, die es Benutzern ermöglicht, Git-Operationen direkt im Windows-Explorer durchzuführen.
https://tortoisegit.org

Gitg (Linux)
Gitg ist ein Open-Source-Git-Client speziell für Linux und bietet eine einfache Möglichkeit zur Verwaltung von Git-Repositories.
https://wiki.gnome.org/Apps/Gitg/

Mit besten Grüßen
Robin

[Jay]

Hallo zusammen,

[...]
Dazu haben wir auch schon bei dem ein oder anderen nachgefragt ob er uns dabei unterstützen kann, doch es ist bisher immer im Sand verlaufen.
[...]

Da sich bei mir keiner zurück gemeldet hat, nehme ich an, dass euch hier jemand anderes bereits hilft. Fehlt euch noch etwas an Information/Hilfe von der Community?

Viele Grüße
Jay

[Tomcraft]

Wir haben jetzt bereits Unterstützung zugesagt bekommen.
Wenn wir weitere Hilfe benötigen, dann melden wir uns hier nochmal.

Grüße

Torsten

[GTB]

Hallo,

wie Torsten schon geschrieben hat, sind wir bereits in Kontakt mit Personen die uns dabei unterstützen.
Die Priorität ist aktuell nicht hoch und wir werden erst mit einem kleinen Teilprojekt starten um uns in den Workflow einzuarbeiten bevor wir das Projekt komplett auf GIT umstellen.

Bitte habt dafür Geduld, dass es noch dauern wird.

Gruss Gerhard