github Workflow / Liveserver etc

ev0lst

Erfahrenes Mitglied
Hallo zusammen,

ich habe mich die letzten 2 Tage mit github beschäftigt und finde es bisher sehr gut, auch wenn der Start mehr als tricky war (haben aber wohl einige gehabt).

Nach wie vor beschäftigen mich folgende Dinge und ich finde einfach keine Antwort:

1) Ich habe derzeit zwei PC's an denen ich den Tag verteilt arbeite (sagen wir "Büro" und "Zuhause"). Ich nutze bevorzugt netbeans und da ist auch eine Verwaltung für git integriert (seit 7.x), alternativ wäre die console auch noch ok.

Ich habe ein repo mit dem Projekt bei github abgelegt und die ssh keys laufen auch alle (auf beiden PCs), wie sollte ich nun jeden PC nutzen um mit dem repo entsprechend arbeiten zu können? fork, upstream, clone.... ?! Da ich mittlerweile so viel darüber gelesen habe, finde ich derzeit keinen richtigen Ansatz, vmtl. zu viel gewesen ;) Hier wäre eine kurze ausführliche Anleitung echt nett, denn so langsam wird es nervig.

2) Das Projekt an dem ich arbeite hatte ich bisher via Remote FTP (netbeans) erstellt und entwickelt, fand ich auch alles klasse bis dahin. Durch github wollte ich mir das alte Problem (kein Überblick bei Anpassungen, keine Entwicklungsstruktur) endlich aus der Welt schaffen. Kann ich, berücksichtigt mit der Kombination aus Frage 1 etwas laufen lassen oder so "bauen", dass es vom repo immer eine Version auf einem Webserver gibt?

Das ganze muss keine Zauberei sein, aber sowas wie test.domain.com wo der aktuelleste Stand des Repo's läuft. Geht sowas? Idealerweise so dass man nicht immer "push'en" muss, aber das wäre noch egal.

3) Allgemein die Frage: Wenn man mit github arbeitet ist ein localhost zu empfehlen? Ich sehe da schon gewisse Vorteile, allerdings bin ich durch Frage 1 auch hier etwas vorsichtig geworden sodass ich es bisher vermieden habe einen localhost zu nutzen. Wenn es hier eine gute (emfehlenswerte) Lösung zu gibt, wäre das mit dem Webserver schon fast überflüssig, denn das war die Lösung dafür dass ich im Grunde nicht sehen und testen konnte bisher. Allerdings würde mich auch hier die Lösung für das pushen auf einen Webserver interessieren. Also das zusammenspiel von Entwickler (localhost) > github > Live-Server (Webserver)


So, das wars auch erstmal. Entschuldigt dass ich vieles vielleicht so kompliziert beschrieben habe, es ist schon spät :) Aber ich weiß mir auch wirklich nicht zu helfen, ich will unbedingt schnellstmöglich weiter am Projekt arbeiten und bisher stieß ich immer wieder auf so kleine doofe Wissenslücken, die aber hoffentlich bald Geschichte sind.

Danke für jede Antwort!
 
Ich habe ein repo mit dem Projekt bei github abgelegt und die ssh keys laufen auch alle (auf beiden PCs), wie sollte ich nun jeden PC nutzen um mit dem repo entsprechend arbeiten zu können? fork, upstream, clone.... ?! Da ich mittlerweile so viel darüber gelesen habe, finde ich derzeit keinen richtigen Ansatz, vmtl. zu viel gewesen ;) Hier wäre eine kurze ausführliche Anleitung echt nett, denn so langsam wird es nervig.
Das kannst du halten wie du willst, Git lässt sehr individuelle Workflows zu. Eigene Projekte klone ich in der Regel, arbeite dann lokal auf einem Feature Branch, den ich regelmäßig in den Master Branch merge und diesen dann pushe.

2) Das Projekt an dem ich arbeite hatte ich bisher via Remote FTP (netbeans) erstellt und entwickelt, fand ich auch alles klasse bis dahin. Durch github wollte ich mir das alte Problem (kein Überblick bei Anpassungen, keine Entwicklungsstruktur) endlich aus der Welt schaffen. Kann ich, berücksichtigt mit der Kombination aus Frage 1 etwas laufen lassen oder so "bauen", dass es vom repo immer eine Version auf einem Webserver gibt?
Wenn du dein Projekt auf GitHub hostest, hast du doch sowieso eine Kopie auf einem Webserver. Ansonsten hindert dich keiner daran, das Repo auch auf einem eigenen Server vorzuhalten.

3) Allgemein die Frage: Wenn man mit github arbeitet ist ein localhost zu empfehlen?
Ein lokales Netzwerkinterface ist auf jeden Fall zu empfehlen, denn soweit ich weiß unterstützt GitHub das Zusenden von Patches auf dem Postweg nicht. Aber im Ernst, ich verstehe nicht was du mit „localhost“ meinst. Einen lokalen Webserver vielleicht?

Grüße,
Matthias
 
Hi Matthias,

danke für die Antwort. Es sind nun einige Tage vergangen und ich habe wieder etwas dazu gelernt. Ich habe nun den idealen Weg gefunden. Jeder PC an dem ich arbeite hat einen localhost (xampp) und ich "pulle" für dem weiter arbeiten den Stand von github und pushe die Stände immer wieder hoch. Nach den Milestones veröffentliche ich dann immer den Stand von github auf dem Webserver. Also soweit alles super, es macht spaß und klappt auch alles.

Aber wenn ich Dich schonmal hier im Thread habe, folgende Frage hat sich nun ergeben: Ich arbeite an einem CMS (als Beispiel) und entwickel bei github dieses immer weiter, habe nun aber ein Projekt womit ich das CMS, mit dem aktuellsten Stand von github, verwenden möchte. Das müsste ich aber logischerweise anpassen (erweitern etc) - wie soll ich vorgehen wenn ich das ganze auch via github machen möchte? Einfach ein neues Repo anlegen mit dem derzeit aktuellsten Stand des CMS und dann GO?

Würde mich mal interessieren was Du dazu sagst, kam nämlich heute in den Raum diese Frage.

Danke!
 
Hallo ev0lst,

wenn ich das jetzt richtig verstanden habe, dann entwickelst du eine Webanwendung und das Kopieren auf einen Webserver ist der Deploy-Schritt? In dem Fall würde ich einen „Live“-Branch anlegen, bei einem neuen Release sämtliche Änderungen des Master-Branches reinmergen, ihn dann auf den Webserver pushen und ein Deployment-Skript als Post-Receive-Hook laufen lassen.

Ich arbeite an einem CMS (als Beispiel) und entwickel bei github dieses immer weiter, habe nun aber ein Projekt womit ich das CMS, mit dem aktuellsten Stand von github, verwenden möchte. Das müsste ich aber logischerweise anpassen (erweitern etc) - wie soll ich vorgehen wenn ich das ganze auch via github machen möchte? Einfach ein neues Repo anlegen mit dem derzeit aktuellsten Stand des CMS und dann GO?
Ich würde einen Fork des CMS-Projektes anlegen. Gegenüber einer (Dateisystem-)Kopie des Codes hat das den Vorteil, dass du sowohl einfach Updates des Originalprojektes in deinen Fork holen als auch im Fork vorgenommene Änderungen „upstream“ zum Originalprojekt zurückfließen lassen kannst.

Grüße,
Matthias
 
Zurück