Wechsel der Eintwicklungsplattform!

[swiss]

Naja den Beitrag und die ganze Umstellaktion bei mir auf dem WG wurde durch dein Aufruf ausgelöst ab sofort keine Änderungen/Fix mehr auf SF einzuchecken... Bedeutet also wenn ich die aktuellste Entwicklerversion testen möchte muss ich zwangsweise subversion auf GIT umstellen

[tht]

Zu github kann ich wenig sagen, da wir im Büro Bitbucket einsetzen, dort kann man branch-spezifisch Rechte vergeben. Bei uns ist es so, dass wir 2-3 Implementierungsdienstleister haben, die für uns entwickeln.

Für den ie Branches master und develop haben nur wir Rechte, die Dienstleister machen sich für die verschiedenen Tasks/Features eigene branches. Wenn ein Feature fertig ist, wird es von uns in develop gemerged und wenn alle Features für einen Release beisammen sind wird auch von uns der Releasebranch erzeugt, von dem dann über ein Buildtool automatisiert der Build erzeugt und auch deployed wird (im Laufe des Jahres wird das noch um Jenkins ergänzt).

Damit haben wir die Kontrolle, aber halt auch die Arbeit mit dem mergen, wobei Konflikte bisher kaum auftreten, da unsere Dienstleister zum regelmäßigen updaten aus develop verpflichtet sind.

Als Client für win/os x kann ich nur sourcetree empfehlen, da es gitflow schön supportet, wobei es da sicher auch andere sinnvolle Alternativen geben mag.

Das sind meine Erfahrungen aus dem kommerziellen Umfeld, ob und wie sich das auf ein Community-Projekt wie die CV übertragen lässt müsst ihr entscheiden. Nach der Eingewöhnung sind die unsere Devs (intern wie extern) happy damit.

Einzig bisher bekannter Nachteil: CI klappt damit nur bedingt, da sich die Features auf unabhängige Branches verzweigen und erst zum Release zusammenfließen. Die nightlys (vom Master oder auch develop) sind also lange Zeit nahezu identisch.

[MicHau]

Wenn ich es richtig verstanden habe, dann sehe ich in gitflow durchaus Vorteile - allerdings mit dem Nachteil, dass jeder Schreibzugriff zum Haupt-Repository (CometVisu/CometVisu) braucht, nicht?

"Jeder" ist zwar relativ, da wirklich jeder forken könnte und dann zumindest "Haupt-Entwickler" mit Schreibzugriff das hinein mergen können. D.h. einer der Haupt-Vorteile der verteilten Entwicklung (man kann mitmachen ohne erst mal irgendwo Zugriff zu bekommen) wäre zumindest halb gegeben.

Nun, bei GitHub kann immer jeder Forken, der einen Account hat und über PullRequests seine Entwicklungen einfließen lassen. Das ist ja grundsätzlich immer gegeben. Die Frage ist eher, wohin (in welchen Branch) lässt er das einfließen und wieviele Personen bekommen Schreibzugriff auf das Haupt-Repository.

• Minimale Einstiegshürde für neue Entwickler (am besten ohne das Gewähren von speziellen Rechten)

Die Hürde ist durch GitHub eigentlich immer minimal. Initial braucht niemand irgendwelche Rechte außer einem Account.

• Minimalen Aufwand für den Maintainer (aktuell ich, aber ich teile gerne die entsprechenden Rechte):
  • insbesondere möglichst keine Konflikte die zu lösen sind(*).
  • Und solange mich kein gutes Tool unterstützt möglichst Point&Click auf der GitHub Homepage (ich entwickle zu selten, als dass ich hier auf der Kommandozeile arbeiten möchte...)
  
  

Und da ich schon gesehen habe, dass das hier gut funktionieren kann, wäre ein erweiterter Wunsch:

• Möglichkeit zum Peer-Review

Das gehört für mich irgendwie zusammen. Im Zusammenhang mit Review kommt eigentlich häufig Gerrit auf den Tisch. Ich habe selbst noch nicht verwendet, es scheint aber genau dafür da zu sein. Vielleicht kann jemand dazu etwas mehr beitragen, der das Tool kennt. Auf die Schnelle habe ich hier eine vermutlich brauchbare Quelle gefunden: Gerrit code review - Tutorial

[dombn]

Hier noch mal eine gute Übersicht, mit der wir im Büro fahren:
A successful Git branching model » nvie.com

Im Prinzip das workflow-Modell, ich finde nur, recht anschaulich dargestellt.

Sinnvollerweise sollten Pull-Requests zu dev, Feature- oder Hotfix-Branches eingereicht werden.

Thema Konflikte: eine gängige Forderung bei Open-Source-Projekten ist es, das Pull Request auf den aktuellen dev-HEAD rebased werden. Das Problem der Konfliktlösung obliegt damit demjenigen der den PR einreicht. Der Maintainer müsste im Zweifel den PR zurückweisen, bzw. um Nachbesserung bitten.

Schreibzugriff auf das Haupt-Repository sollten IMHO so wenige wie möglich bekommen, sonst hätte ich Sorge, dass zu schnell »Wildwuchs« entstünde.

[mfd]

=> Bitte nichts mehr bei SourceForge einchecken (Betrifft erst mal nur die CometVisu, alle anderen Teilprojekte von OpenAutomation bleiben erst mal auf SourceForge)
=> Für alle bestehenden Autoren: bitte teilt mir eueren GitHub Namen so wie den SourceForge Namen mit. Ich glaube die kann ich noch irgendwie verlinken...

Betrifft mich das mit den Icons jetzt auch direkt? Dann muss ich mich mal in die Thematik einarbeiten. Ich war bisher schon froh, dass ich mit dem SVN klargekommen bin .

Was genau ist mit "Designer/Künstler/Grafiker" gemeint, bzw. was wäre da der Aufgabenbereich? Das geht aus dem Anfangsbeitrag leider nicht so genau hervor.
Nicht dass ich mich als einer davon oder gar alles zusammen bezeichnen würde, aber wenn es um den Look bzw. eine grafische Weiterentwicklung der CV geht könnte ich mich evtl. mit einbringen...

[Chris M.]

Betrifft mich das mit den Icons jetzt auch direkt?

Wie Du willst

Erst mal nein, es ist nur die CometVisu nach GitHub gewandert. Alles andere (die das KUF-Iconset, WireGate Plugins, ...) ist erst mal auf SourceForge geblieben.

Wenn Du aber wechseln willst - kein Problem.

Was genau ist mit "Designer/Künstler/Grafiker" gemeint, bzw. was wäre da der Aufgabenbereich? Das geht aus dem Anfangsbeitrag leider nicht so genau hervor.
Nicht dass ich mich als einer davon oder gar alles zusammen bezeichnen würde, aber wenn es um den Look bzw. eine grafische Weiterentwicklung der CV geht könnte ich mich evtl. mit einbringen...

Sehr gut!

Näheres bitte in einem neuen Thread - daher nur ein paar Stichpunkte: ein/mehrere hübsche neue Design[s] ausdenken und per CSS realisieren.

Was möglich ist, kann man ja an den bestehenden Designs sehen (insb. an "Planet" wo ich mal versucht hatte CSS ganz weit zu biegen - und ich denke erfolgreich, auch wenn ich mit dem aktuellen Zustand von Planet nicht sonderlich zufrieden bin. Aber ich habe da bewusst die Maintainer-Rolle abgegeben und will daher auch nicht meckern)

[makki]

Wie sollen wir uns nun entscheiden? Wer kann hier beraten?

Ich will jetzt den Thread nicht kapern, aber da es direkt miteinander zu tun hat und dieselben Ziele bestehen:

Exakt die gleiche Fragestellung gilt für
github.com/Makki1/knxd
https://knx-user-forum.de/knx-eib-fo...fork-knxd.html

Ich bin in Github ebenso "blank"..

Makki

[Chris M.]

Hier noch mal eine gute Übersicht, mit der wir im Büro fahren:
A successful Git branching model » nvie.com

Wenn ich das richtig verstanden habe, dann ist das eine Interpretation des gitflow Modells, nicht?

Was müssen wir genau festlegen um jetzt so ein Arbeitsmodell bei uns "festzuschreiben"? Einfach auf diesen Link verweisen?

Was wir auf jeden Fall auch machen müssten ist eine Anleitung für "nur Nutzer" (in der Sprache des anderen Thread: für technisch Interessierte), die uns ja gutes Feedback beim Testen geben. Deren Fokus sehe ich in regelmäßigem Updaten von (und gelegentlichem Switchen zwischen) develop und release.

Schreibzugriff auf das Haupt-Repository sollten IMHO so wenige wie möglich bekommen, sonst hätte ich Sorge, dass zu schnell »Wildwuchs« entstünde.

Eine gewisse Redundanz würde ich schon vorschlagen. Es gibt ja noch einen Unterschied zwischen Berechtigung haben und Berechtigung nutzen.

Aber im Gegensatz zum SVN können wir gerne erst mal mit einem Minimum von erprobten Entwicklern anfangen (ich schlage in Summe 3 vor). Wer will?
(Wenn's gut läuft könnten wir da dann ein wirklich gutes Peer-Review machen, d.h. dass alle - inkl. meiner - Patches da durch müssen; Aufgabe von diesen - nennen wir sie mal in Ermangelung eines besseren Begriffes - "Reviewer" wäre dann regelmäßig anstehende Patches auch zu kommentieren oder zu akzeptieren)

[dombn]

@Chris

Ja, ist es. Ich finde nur die Darstellung sehr übersichtlich und die Erklärungen, gerade für Einsteiger, sehr hilfreich. Falls Interesse besteht, kann ich gerne noch ein paar Links zu hilfreichen git-Anleitungen/Hilfen beisteuern.

Wenn die Pull Requests sauber aufgebaut sind (und auf den HEAD des jeweiligen Branches »rebased« sind), können die normalerweise sehr einfach angenommen werden (rein technisch und nicht bezogen auf den Review).

[makki]

git hat mich (woanders) zwar gerade mal wieder 4h an den Rande des Wahnsinns getrieben, aber es wird schon irgendwo seinen Sinn haben
Als "Backup"-Admin (so wie es ChrisM ungefragt für knxd ist) ohne Verpflichtung dazu, stelle ich mich zur Verfügung..

Makki

[Chris M.]

So, unter https://github.com/CometVisu/CometVi...pment-workflow hab ich jetzt mal das Modell "festgehalten" - jetzt muss ich nur noch bisschen Branchen gehen und die Wiki-Seite[n] müssten aktualisiert werden.

[Chris M.]

So, jetzt versuche ich gerade den neuen Workflow zu leben und bin schon verwirrt. Kann mir hier jemand erklärend helfen?

Konkret möchte ich an der Umwandlung von JQuery-Objekten zu Strings weitermachen.

https://github.com/CometVisu/CometVisu/ hat inzwischen neben dem master-Branch für die Releases auch noch einen develop-Branch für die Entwicklungen.
Für die Umwandung der Objekte habe ich nun einen "feature branch" mit dem Namen textify_widgets angelegt.

Ich glaube das ist noch nach dem Konzept. Aber wie geht's weiter?

"Privat" habe ich ja den Fork unter https://github.com/ChristianMayer/CometVisu/. Wenn nun alles richtig verstanden habe, dann muss ich meine Änderungen, die ich lokal mache, dagegen einchecken. Und dann von dort nach CometVisu/CometVisu->textify_widget (was ist eigentlich die Notation für einen Branch in einem Repository?).
Oder muss ich unter ChristianMayer/CometVisu auch noch einen Branch "textify_widgets" anlegen, alles lokalen Änderungen dagegen (also ChristianMayer/CometVisu->textify_widget) machen und dann von dort nach CometVisu/CometVisu->textify_widget?

Kann ich eigentlich irgendwie die Doppel-Arbeit verringern, dass ich meine Datei-Edits lokal einchecken muss und dann das lokale nach ChristianMayer/CometVisu hochladen muss? D.h. kann ich beides auf einmal machen?

Und wie stelle ich ein, gegen welchen Branch von CometVisu/CometVisu der Fork ChristianMayer/CometVisu synchronisiert werden soll?

[JNK]

Hallo Chris,

meinem Verständnis nach, ist ein feature_branch im Haupt-Repo nicht erforderlich, wenn Du geforked hast. Dann machst Du in deinem Fork einen Branch von develop.

Dann hast Du quasi in Deinem "Privat-Repo"

privat/master
privat/develop
privat/feature1

Wenn Du das dann ins Haupt-Repo bringen willst, machst Du einen Pull-Request von privat/feature1 nach cometvisu/develop, nachdem du vorher alle zwischnezeitlichen Änderungen von cometvisu/develop in Dein privat/develop und privat/feature1 übernommen hast. Dann geht der Merge hinterher auch konfliktfrei.

Commit und Push in einem Schritt geht glaube ich nicht, der Gedanke ist wohl, dass man die Commits sehr klein und übersichtlich halten kann und mit einem Push dann mehrere Commits die zu einem Feature gehören zusammen ins Repo bringt.

Gruss,

der Jan

[tht]

Für mein Verständnis liegt hier noch ein kleines Missverständnis vor:
Gitflow ist von seiner Intention her ein zentralisierter Workflow, der weniger auf das Forken sondern das Branchen setzt:

The Gitflow Workflow still uses a central repository as the communication hub for all developers. And, as in the other workflows, developers work locally and push branches to the central repo.

Viele Projekte auf GitHub setzen stattdessen auf einen dezentralisierten Workflow, siehe auch eine weitere Erklärung auf git-scm.com.

Bei GitFlow arbeitet man mit einem einzigen zentralen Repository, darin existieren dann auch die verschiedenen Feature-Branches. Wie du selbst unter https://github.com/CometVisu/CometVi...pment-workflow ergänzt hast (wenn vermutlich auch eher reibkopiert), dürfen die Feature-Branches bis auf einige reservierte Namen jeglichen Namen haben.

Bei uns im Büro haben wir als Konvention "feature/*", wobei das Sternchen dann der Ticket-ID entspricht (liegt aber an unserem Gesamt-workflow mit Jira-Integration, worüber dann auch die Branches aus Issues heraus erstellt werden), das kann man aber halten wie man will. Nur master, develop, release-* or hotfix-* darf man nicht nehmen.

Du würdest also wohl lokal den Branch "textify_widgets" erstellen, darin arbeiten, ihn lokal committen und abschließend pushen. Wenn du fertig bist, muss er dann in develop übernommen werden (merge oder rebase, dazu überlasse ich dombn weitere Ausführungen). Danach kann der Feature-Branch gelöscht werden.

Um einen Release zu bekommen, wird dann irgendwann (wenn alle gewünschten Features oder auch einfach "genug" Features beisammen sind) ein Branch "release-RELEASENUMMER" von develop aus erstellt. Alle weiteren Arbeiten für diesen Release finden dann nur in diesem Branch statt! Test-Deployment -> Test -> Fix. Wenn der Release fertig ist, wird er nach master und develop gemerged, ein Tag auf master erstellt und der Release-Branch gelöscht.

Hotfixes eines bestehenden Releases werden von Master aus gebrancht, danach analog zu einem Releasebranch.

[JNK]

@tht:

So hatte ich das auch verstanden. Was Chris im Augenblick macht ist mehr das was im Atlassian Tutorial "Forking" ist, mit Elementen von Gitflow. Mit ein wenig Disziplin (es wird erst nach Review nach develop und erts recht nicht direkt nach master gepushed), sollte das mit einem Repo eigentlich auch gehen. Wir sind ja nicht hunderte Developer.

Auf der anderen Seite hat das Forken auch was, es reduziert die Fehlermöglichkeiten beim Pushen.

Gruss,

der Jan