Neben den Vorteilen die es gibt, wenn du dein eigenes Projekt startest, gibt es auch einige Vorteile, wenn du an Projekten von anderen mitarbeitest. Der Kernnutzen, den ich durch die Mitarbeit an Projekten auf GitHub für mich sehe ist das Reflektieren.

Die Basis um kontinuierlich besser, oder sagen wir anders, zu werden ist für mich das Reflektieren. Mir geht es beim Reflektieren darum, dass ich Werte habe und versuche meine Handlung an diesen Werten auszurichten. Dabei strebe ich kontinuierlich danach meine Werte möglichst effektiv umzusetzen. Ein konkretes Beispiel dafür ist bei mir "Clean Code". Ich versuche also meinen Quellcode immer sauberer zu gestalten.

Wie weiß ich nun jedoch ob mein Quellcode bereits sauber ist? In welche Richtung kann ich ihn vielleicht noch sauberer gestalten? Das erkenne ich einerseits in dem ich Bücher lese, Kurse absolviere und so weiter. Ich lerne also. Das Theoretische reicht mir jedoch nicht. Es geht auch immer um die praktische Umsetzung.

Genau dafür ist GitHub eine geniale Plattform. Erstmal gibt es unglaublich viele Projekte, die ich analysieren kann bezüglich Aspekten die ich gut finde und auch Aspekten die mir nicht gut gefallen. Häufig ist es erstmal nur eine Art Bauchgefühl. Ich schaue also einen Quellcode an und habe irgendwie das Gefühl, dass er richtig cool ist, oder das etwas nicht stimmt.

Mit diesem Gefühl fange ich dann an zu suchen was genau das coole oder das komische ist. Finde ich Code Smells, die mir zeigen, dass etwas nicht stimmt? Sehe ich vielleicht eine coole Designmethodik (wie zum Beispiel Domain Driven Design) die in dem Quellcode angewandt wurde? ...

So lerne ich, kann meine Werte festigen und vor allem bekomme ich praktische Erfahrung. Dabei geht es mir hauptsächlich darum Muster zu erkennen. Das Erkennen von Mustern hilft mir später, wenn ich selber Quellcode schreibe. Bin ich in einer ähnlichen Situation wie die Entwickler in einem Projekt welches ich auf GitHub angeschaut und analysiert habe, dann kann ich vielleicht die Lösung von dort verwenden. Unter Umständen habe ich auch ähnlichen Quellcode in meinem Projekt, der mir nicht gefällt. Dann kann ich mir Gedanken machen wie ich ihn entfernen kann. Das alles sind Muster die mich langfristig effektiver und professioneller Software entwickeln lassen.

Ein weiterer Schritt ist dann nicht nur die passive Arbeit an einem Projekt, sondern das aktive Beteiligen an einem GitHub-Projekt. Viele Entwickler die auf GitHub ihre Projekte haben, sind dankbar, wenn du sie auf bestimmte Aspekte ihres Projektes ansprichst. Egal ob du eine Verständnisfrage hast, ob du ein Problem gefunden hast oder auch eine Idee hast um das Projekt weiterzubringen. Durch aktive Beteiligung lernst nicht nur du, sondern auch die anderen.

Lernen und üben sind jedoch nicht die einzigen Gründe warum du dich an anderen Projekten auf GitHub beteiligen solltest:

• Kooperationen - Sobald du anfängst und beteiligst dich an Projekten, oder auch wenn du eigene Projekte veröffentlichst, kommen immer wieder Entwickler auf dich zu. Für mich haben sich daraus schon einige spannende Diskussionen und Kooperationen ergeben. Zeigst du, dass du bereit bist auch ohne finanzielle Entlohnung etwas für andere zu machen, dann wird das auch anders herum gehen.
• Selbstmarketing - Es ist fraglich, ob das "kostenlose" Geben deine einzige Motivation sein sollte. Wie ich bereits gesagt habe, ist ein entscheidender Punkt, dass du dabei viel lernst und übst. GitHub macht in diesem Kontext allerdings noch etwas sehr wichtiges für dich. Es vermarktet deine Engagement. Es ist in deinem Profil sichtbar in welchen Projekten du dich beteiligst und auch was und wie du daran arbeitest. Wenn du also anderen Projekten auf GitHub hilfst, präsentierst du auch gleichzeitig deine Fähigkeiten. Potentielle Arbeitgeber und Kunden können so recht schnell heraus finden was du machst und wie du arbeitest.
• Wiederverwendung - Viele Projekte auf GitHub bieten einen wirklich immens großen Nutzen. Je nach Lizenz kannst du diese Projekte sehr einfach in deinem eigenen Projekt verwenden. Du brauchst also nicht alles selber zu entwickeln, sondern kannst vorhandenes weiterverwende. Was allerdings, wenn das vorhandene fast perfekt ist, aber eben noch nicht ganz optimal für dein Projekt ist? Was wenn es einen Fehler gibt, der insbesondere für dein Projekt ein Problem darstellt? Die Idee bei GitHub und Open Source im allgemeinen ist, dass du einfach behilflich bist den Fehler zu beheben. Damit investierst du ein wenig deiner Zeit, aber bekommst eine riesige Zeitersparnis zurück.

Gibt eine allgemeine Einführung in die grundsätzlichen Aktivitäten des GitHub-Workflows.

In der vorherigen Lektion hast du gesehen wie du dich in anderen Projekten einbringen kannst bzw. wie andere Entwickler auch an deinem Projekt arbeiten können. In dieser Lektion gebe ich dir einen kurzen Überblick wie das GitHub-Team intern GitHub verwendet. Dort wird ein relativ einfacher Workflow verwendet, der auch dir helfen kann. Dabei ist es egal ob du in einem (kleinen) Team arbeitest oder auch alleine.

Im Vergleich zu der vorherigen Lektion besteht hier der Hauptunterschied darin, dass du mit dir bekannten Personen zusammenarbeitest. Trotzdem werden Pull-Requests verwendet um einerseits eine Dokumentation zu haben und andererseits einen klar definierten Workflow. Natürlich kannst du das auch alles viel informeller in deinem eigenen Projekt gestalten. Allerdings ist dieser Workflow sehr einfach nachvollziehbar und erfüllt trotzdem alle wesentlichen Aspekte der Qualitätssicherung und unterstützt die Zusammenarbeit im Team.

Die wichtigsten Punkte sind:

• Der "master" Branch hat immer eine lauffähige Version
• Wenn du an etwas neuem arbeitest (neues Feature, Bugfix, ...) erstellst du einen Branch von "master" mit einem entsprechenden Namen (z.B. "save-business-model-to-xml")
• Du machst kontinuierlich Commits für deine Änderungen in dem lokalen Branch und schiebst diesen dann regelmäßig auf einen remote Branch mit dem gleichen Namen auf dem Server
• Wenn du Fragen hast, eine Meinung von einem Kollegen brauchst oder denkst, dass du fertig bist und ein abschließendes Code-Review haben möchtest, erstellst du einen "Pull Request".
• Sobald jemand deine Änderungen angeschaut und bestätigt hat, kannst du deinen Branch in den "master" Branch mergen
• Sobald deine Änderungen in den "master" Branch gemergt sind, solltest du einen kompletten Build machen um sicherzustellen, dass alles funktioniert

http://scottchacon.com/2011/08/31/github-flow.html

https://guides.github.com/introduction/flow/

Talking Head.

Natürlich stellt sich die Frage warum du überhaupt auf einer Plattform wie GitHub ein Projekt starten solltest. Erstmal sollte dir bewusst sein, dass auf GitHub zwischen öffentlichen und privaten Projekten unterschieden wird. Wahrscheinlich bist du bereits über einige öffentliche Projekte gestolpert. Gerade, dass Microsoft in den letzten Monaten massiv in GitHub-Projekt investiert hat zeigt, dass es wohl einen oder mehrere gute Gründe dafür gibt:

• Community - Egal ob du an riesigen Projekten arbeitest wie Microsoft oder ein Ein-Mann/Frau-Projekt betreibst, es gibt gleich zwei wichtige Gründe die Community in dein Projekt zu involvieren. Zum einen ist es das Feedback. Du bekommst über Issues, Stars, Watching und Follower direkte Rückmeldung von Leuten ob sie dein Projekt und/oder deine Arbeit interessant finden. Du kannst also mit potentiellen Nutzern in Kontakt treten, wenn sie denn auf GitHub aktiv sind. Zum anderen hast du auch die Möglichkeit, dass du andere Leute findest die dich bei deiner Arbeit unterstützen. Bei über 14 Millionen Nutzern ist die Wahrscheinlichkeit, dass es noch mehr Leute gibt, die das gleiche oder ein ähnliches Probleme wie du lösen wollen nicht gerade gering.
• Selbst-Marketing - Ein weiterer immer wichtiger werdende Aspekt ist das Marketing. Wenn du auf GitHub ein oder mehrere Projekte hast, ist das für potentielle Arbeitgeber (egal ob du Angestellter oder Freiberufler bist) interessant. Immer mehr Vorgesetzte im Softwareentwicklungsbereich kennen die Vorzüge von GitHub. Denn dort können sie deine Arbeit im Detail ansehen. Wenn du also auf der Suche nach einem neuen Job oder Projekt bist, solltest du ein aussagekräftiges Projekt auf GitHub pflegen. Damit kannst du jedem dein Verständnis von gutem Quellcode zeigen und deine Arbeitsweise vorstellen.
• Recruiting - In die andere Richtung funktioniert das auch. Wenn du eine Firma betreibst, dann kannst du über Projekte auf GitHub zeigen wie spannend die Arbeit bei dir ist. Dadurch, dass sich Entwickler in dein GitHub-Projekt einbringen können, hast du die Möglichkeit potentielle Arbeitnehmer kennenzulernen.

Neben diesen Vorteilen, ist für mich persönlich der Aspekt der Datensicherung sehr wichtig. Es gibt schon fast unendlich viele Möglichkeiten seine Daten zu sichern. Allerdings finde ich, dass es möglichst einfach gehen sollte, damit ich es auch tatsächlich mache. Die Einbindung eines GitHub-Projektes in meine tägliche Arbeit ist genau das: überaus einfach! Dabei spielt es keine Rolle ob ich meinen Quellcode für alle sichtbar in einem öffentlichen oder nur für mich und mein Team in einem privaten Verzeichnis ablege. Ich kann auf beide direkt aus meiner Entwicklungsumgebung zugreifen und sämtliche Änderungen die ich lokal habe mit meine GitHub-Projekt synchronisieren. So kann ich mir sicher sein, dass meine Daten nicht verloren gehen.

Eines der Kernelemente auf GitHub ist das Verzeichnis (engl. Repository). Das kannst du dir so wie ein Projekt vorstellen. Ein solches Projekt besteht aus den folgenden Funktionalitäten, die GitHub anbietet:

• Code-Hosting - Dieses ist die erste Kernfunktionalität von GitHub. Es geht darum ein Verzeichnis für Quellcode bereit zu stellen. Ähnliches kannst du auch realisieren, wenn du deinen Quellcode in deine DropBox lädst.
• Versionsverwaltung - Dieses ist die zweite Kernfunktionalität von GitHub. Dein Quellcode-Verzeichnis wird per Git verwaltet und du kannst darauf per Git zugreifen. Damit hast du einen wesentlichen Vorteil gegenüber der Lösung deinen Quellcode einfach auf DropBox zu kopieren. Die Versionsverwaltung umschließt komplett das Code-Hosting. Du hast also keine Möglichkeit Dateien ohne eine Versionierung auf GitHub zu speichern.
• Issue Tracking - Ein weiterer wichtiger Bestandteil eines GitHub-Verzeichnisses ist das Erstellen und Verwalten von Issues. Diese Funktionalität ist entscheidend für das sogenannte "Social Coding". Allerdings kannst du sie für jedes GitHub-Verzeichnis ausschalten.
• Wiki - Jedes Projekt auf GitHub kann sich ein Wiki einrichten. Dabei handelt es sich wieder um ein Git-Verzeichnis. Allerdings ist dieses separat vom Quellcode. Auch das Wiki ist nur optional für dein GitHub-Projekt.
• Project-Pages - GitHub bietet mit den GitHub-Pages eine einfache Möglichkeit eine Webseite zu erstellen. Zu jedem GitHub-Projekt kannst du eine eigene Webseite erstellen. Der entsprechende Inhalt dafür liegt auch in deinem GitHub-Verzeichnis. Genau wie das Wiki und die Issues, sind die Project-Pages optional!

Du kannst für jedes Projekt entscheiden ob es öffentlich sichtbar ist, oder nur für dich bzw. deine Organisation / Teams deiner Organisation. Dieses ist auch einer der Hauptunterschiede zu anderen Plattformen wie BitBucket oder Visual Studio Team Services. Die beiden letzteren bieten nur private Projekte an. Auf GitHub findest du mittlerweile jedoch fast jedes bekanntes (und unbekanntes) Open-Source-Projekt. Da öffentliche Projekte auf GitHub kostenlos sind, ist es wohl ein entscheidender Faktor warum GitHub so bekannt ist.

Wenn es um private Projekte geht, dann haben andere Plattformen schon teilweise wesentlich umfangreichere Möglichkeiten. So hat beispielsweise Microsoft in Visual Studio Team Services eine umfangreiche Projektmanagementlösung integriert die nahtlos aus Visual Studio bedient werden kann. Es ist daher in diesem Bereich die mächtigere Lösung. Allerdings ist das auch für viele Projekte eine totale Überforderung.

Zusammenfassung

GitHub wird häufig als ein Verzeichnis von Open-Source-Projekten angesehen. Jeder kann sein GitHub-Verzeichnis (häufig auch Projekt genannt) öffentlich sichtbar machen, oder auch als privates Projekt führen. Funktionalitäten wie Issues, Wikis und Project-Pages sind wichtige Elemente für das von GitHub geprägte "Social Coding". Der Zugriff auf Projekte wird über Zugriffsrechte verwaltet die bei GitHub hauptsächlich über Organisationen und Teams definiert werden.

Die wichtigsten Funktionen habe ich dir bereits in der vorherigen Lektion vorgestellt. Hier geht es darum, dass du verstehst, über welche Kanäle du GitHub bedienen kannst.

• Webinterface
• Git - z.B. direkt aus deiner IDE
• Integrations
• GitHub API

Screencast.

Ein Profil auf GitHub ist der zentrale Anlaufpunkt um dich über einen Entwickler zu informieren. Für dich bedeutet das, dass du dich hier präsentieren kannst. Auf einige Aspekte hast du dabei Einfluss. Andere werden von GitHub automatisch erstellt.

Daten die in deinem Profil sichtbar sind, kannst du in den Einstellungen anpassen. Dort solltest du folgende Einstellungen unbedingt anpassen:

• Profile picture (finde ich persönlich wichtig, wird aber nicht viel gemacht)
• EMail & URL - wenn du eine eigene Webpräsenz hast
  • Primäre-Adresse kann von anderen gesehen werden. (Egal was du bei Public-Email eingestellt hast.)
• Notifications sag GitHub wie und wo du informiert werden möchtest
  • Wenn jemand Kommentare zu deinem Verzeichnis macht, macht es Sinn, dass du per Email informiert wirst. So kannst du umgehend Antworten, was immer einen guten Eindruck macht.

Du lernst, wie du ein neues Projekt auf GitHub anlegst und was du dabei bedenken / beachten solltest:

• Eine Beschreibung hilft!
• Private-Repositories sind kostenpflichtig
• Im README.md kannst du etwas mehr zu deinem Projekt erklären.
• Setze explizit eine Lizenz für dein Projekt

Nachdem das Projekt erstellt ist, kannst du auch hier deine Webseite verlinken. Das wichtigste jedoch ist, dass du ein paar Sätze ins README.md schreibst.

GitHub ist International. Überlege dir also, in welcher Sprache du schreibst!

Du lernst die wichtigsten Bestandteile deines GitHub-Projektes kennen:

• Code - Hier siehst du deinen Quellcode und kommst zur Historie
  • Download ZIP - der aktuelle Stand deines Quellcodes wird in eine ZIP-Datei gepackt und auf deinen Rechner geladen.
  • Verzeichnisname - Diesen brauchst du, um dein Verzeichnis per Git auf deinen Computer zu bekommen.
  • Commits - Zeigt wie dein Quellcode geändert wurde (Git-Historie)
  • Releases - Hier kannst du ausführbare Versionen deiner Anwendung bereitstellen
• Wiki - Wenn du zusätzliche Dokumentation zu deinem Projekt benötigst
• Settings - Hier kannst du Funktionen wie Wiki für dein Projekt deaktivieren
  

Nun bist du dran! Erstelle ein Konto, konfiguriere es und starte dein erstes Projekt.

Wenn du lediglich den Quellcode von einem für dich interessanten Projekt in VisualStudio anschauen willst, dann kannst du dir dieses Projekt klonen.

Dazu benötigst du die Adresse des Projektes und schon geht es los.

WICHTIG: Wenn du ein Projekt, welches nicht dein eigenes ist, von GitHub klonst, kannst du an dem Projekt zwar lokal arbeiten, aber deine Änderungen nicht wieder in das Projekt zurück fließen lassen. Wenn du das machen möchtest, musst du erst ein Fork vom Projekt erstellen.

Wenn du nun ein neues Projekt auf GitHub angelegt hast, dann hast du zwar schon ein paar Dateien, aber das eigentlich wichtige, der Quellcode, fehlt bisher noch. In dieser Lektion zeige ich dir, wie du deinen Quellcode aus Visual Studio in dein neues GitHub-Projekt bekommst.

Es gibt einige Möglichkeiten wie du ein neues oder auch bestehendes Projekt von Visual Studio mit deinem Projekt auf GitHub synchronisieren kannst. In dieser Lektion stelle ich dir den aus meiner Sicht reibungslosesten Weg vor:

1. Dein GitHub-Projekt klonen (siehe vorherige Lektion)
2. Im übergeordneten Verzeichnis ein neues VS-Projekt erstellen (mit dem gleichen Namen)
3. Die Solution der Quellcodeverwaltung hinzufügen
4. Einen lokalen Commit machen
5. Im TeamExplorer (Visual Studio) synchronisieren

Wenn du nun ein neues Projekt auf GitHub angelegt hast, dann hast du zwar schon ein paar Dateien, aber das eigentlich wichtige, der Quellcode, fehlt bisher noch. In dieser Lektion zeige ich dir, wie du deinen Quellcode aus Visual Studio in dein neues GitHub-Projekt bekommst.

Nicht immer fängst du mit einem VisualStudio Projekt neu an. Wenn du also ein schon bestehendes VisualStudio-Projekt mit einem neuen GitHub-Projekt synchronisieren möchtest, dann hilft dir diese Lektion. Folgende Schritte sind auszuführen:

Nachdem du das Projekt aufgesetzt hast, bist du erstmal der alleinige Herrscher über dein Projekt. D.h. andere können dein Projekt sehen, sie können es sogar kopieren und dir Änderungen vorschlagen. Sie können jedoch nicht direkt Änderungen an deinem Quellcode machen.

Das ist nun häufig erstmal der richtige Weg, aber vielleicht möchtest du ja mit jemanden zusammen arbeiten. Wenn du diesem jemanden traust, dann kannst du ihn als Collaborator in dein Projekt aufnehmen. Damit hat er direkten Schreibzugriff auf dein Projekt und kann den Quellcode verändern.

GitHub hat eine umwerfende Suchfunktion. Allerdings ist sie nicht immer sofort verständlich. Folgende Aspekt stelle ich dir in dieser Lektion vor:

• Suche global oder in einem Projekt
• Wonach suchst du? Schränke die Ergebnisse auf Verzeichnisse, Code oder Issues ein.
• Welche Technologie verwendest du? Schränke die Ergebnisse auf deine Programmiersprache ein.
• Filtere die Ergebnisse

GitHub ist nicht nur eine Visualisierung für die Versionsverwaltung Git, sondern auch eine Art soziales Netzwerk für Entwickler und alle die an Softwareentwicklungsprojekten teilnehmen wollen. Es gibt ein paar Informationen die dir zeigen wie aktiv ein Projekt ist. Es gibt momentan über 31 Millionen Projekte. Allerdings werden viele davon auch nicht aktiv gepflegt.

Folgende Indikatoren können dir bei der Bewertung helfen:

• Wann war der letzt Commit?
• Wie ist der Puls des Projektes?
• Wie aktiv ist das Projekt über die Laufzeit und wer sind die wichtigsten Entwickler?

Wenn du dir das "Network" ansiehst, kannst du erkennen an welchen Funktionalitäten momentan gearbeitet wird. Darum ist es auch sehr wichtig, dass du gut benannte Branches verwendest. Nur so sehen andere woran momentan gearbeitet wird.

https://gun.io/blog/how-to-github-fork-branch-and-pull-request/

In dieser Lektion gehst du selber auf die Suche nach einem für dich passenden Projekt und entscheidest anhand deiner Bewertung, ob du es unterstützen möchtest.

Auf GitHub werden Issues für ziemlich viel benutzt. Es ist der Mechanismus um mit den Entwicklern eines Projektes in Kontakt zu treten. Dabei kannst du grundsätzlich ein Issue verwenden um

• eine Frage zu stellen
• ein Problem zu berichten
• einen Fehler zu berichten

Du solltest allerdings bedenken, dass ein Issue immer Arbeit für die Entwickler bedeutet. In kleinen Projekten kann es vorkommen, dass es länger dauert bis du eine Antwort bekommst, weil der einzige Entwickler vielleicht gerade Urlaub macht. In großen Projekten können sehr viele Issues an einem Tag gestellt werden. Auch hier wollen die Leute etwas anderes tun als nur Fragen zu beantworten.

Wenn du dich mit einem Projekt beschäftigst und dort aktiv werden möchtest, dann sind Issues ein guter Einstieg. In dieser Lektion erfährst du, wie du ein Issue erstellst. Dabei gehe ich auf folgende Punkte ein:

• Verwende die Projektsprache!
• Suche in den bereits geschlossenen Issues
• Der Titel ist wichtig (auch für später)
• @ - Projektmitglieder ansprechen
• # - Referenz auf andere Issues / Pull Requests
• Du kannst dem Bearbeiter eines Issues Zeit ersparen, wenn du einige Basisinformationen zur Verfügung stellst.
• Gerade bei größeren Projekten gibt es häufig eine Vorlage was in einem Issue enthalten sein sollte

In dieser Lektion wendest du dein Wissen über Issues praktisch an.

Die Zustandsmaschine für Issues ist bei GitHub sehr einfach gehalten. Ein Issue kann lediglich die folgenden Zustände haben:

• Open - Von der Erstellung bis zum Schließen eines Issues
• Close - Sobald ein Issue über die Oberfläche oder via einer commit-message / pull-request geschlossen wurde
• Reopen - Projektteam sieht bei jedem geschlossenen Issue einen zusätzlichen Button zum erneuten öffnen eines Issues.

Darüber hinaus gibt es keinen fest definierten Workflow oder Zustände eines Issues. Alles weitere kannst du mithilfe von Milestones und insbesondere Labels für dein Projekt definieren. Dabei wirst du allerdings nicht wie bei anderen Issue-Trackern vom Tools selbst unterstützt.

Wie ist das mit diesen Bots, die ich schon einigele gesehen habe (z.B. vscode hat einen "mentionbot")?

Auch die Zugriffsrechte sind sehr einfach gehalten: Jeder GitHub-Benutzer kann an öffentlichen Projekten ein Issue erstellen und kommentieren.

Lediglich beim schließen von Issues gibt es eine (gravierende) Einschränkung. Ein Issue kann nur vom Projektteam und dem Autor des Issues geschlossen werden.

Gerade in großen Projekten mit vielen Issues wirst du häufig sehen, dass es besondere Hinweise an Issues gibt. Dies sind dann entweder Milestones, Labels oder Assignees. Damit ist es leichter sich in der Flut von Issues zu orientieren, aber es hilft auch sehr bei der Projektplanung und dem Projektmonitoring. Hier ein paar Details und Beispiele:

• Milestones - Sind eine Gruppe von Issues die zu einem bestimmten Projekt, Feature oder Zeitpunkt gehören. Du könntest zum Beispiel alle Issues die im nächsten Sprint (nächste Iteration) bearbeitet werden sollen einem Milestone zuweisen. Genauso könntest du auch sagen, dass du alle Issues für das erste Beta-Release zusammen fasst.
• Labels - Bieten dir eine Möglichkeit unterschiedliche Arten von Issues zu organisieren. So könntest du beispielsweise ein Label "Dokumentation" erstellen für alle Issues die sich auf die Dokumentation beziehen. Du könntest auch Labels für "Feature" und "Bug" erstellen um Issues bezüglich Fehlerbehebung und neuer Funktionalität von einander zu trennen.
• Assignee - Wenn du mit mehreren Leuten an einem Projekt arbeitest, dann kannst du jemandem die Verantwortung für ein Issue zuweisen. Damit ist nicht unbedingt gemeint, dass diese Person das Issue löst. Vielmehr geht es darum, dass sich die Person darum kümmert, dass es gelöst wird.

Du kannst diese Funktionalitäten jedoch nicht nur in großen Projekten benutzen, sondern ebenfalls in deinem eigenen (kleinen) Projekt. Gerade dort kannst du dir so ein einfaches Projektmanagement mit den "Bordmitteln" von GitHub erstellen.

Wenn du dich mit Kanban-Boards auskennst, dann ist vielleicht auch https://huboard.com für dich interessant. Es ist ein für Open-Source-Projekte kostenloser Service mit dem du Issues auf einem Kanban-Board organisieren kannst.

Um zu sehen, welche Issues du erstellt hast und wie es um deine Issues steht, kannst du einen Blick in das Issue-Dashboard schmeißen. Dieses findest du, wenn du oben auf "Issues" klickst.

Wenn dich das Projekt mehr interessiert als deine eigenen Issues, dann kannst du dir den "Pulse" anschauen. Dort siehst du, wie sich die Issues für das Projekt entwickeln.

Auch Visual Studio hat die Funktionalität, dass es Issues verwalten kann. Nun ist es erstmal nicht direkt möglich, die Issues von GitHub in Visual Studio zu sehen. Dafür gibt es jedoch eine Extension. In dieser Lektion zeige ich dir, wie du sie installierst und verwendest.

Ein Fork ist quasi eine Kopie eines bestehenden Verzeichnisses. Dies wird hauptsächlich aus den folgenden Gründen gemacht:

• Du möchtest etwas für dich ändern, aber nicht von vorne anfangen
• Du möchtest etwas zu einem Projekt beisteuern

Dabei ist die grundsätzliche Idee, dass du ein paar Modifikationen an einem Projekt machen möchtest. So habe ich beispielsweise meine Webseite auf einer bestehenden Codebasis angefangen. Das schöne dabei ist, dass ich Änderungen die nach dem Fork am Ursprungsprojekt gemacht wurden in mein geändertes Projekt integrieren kann. In meinem Fork habe ich allerdings die Kontrolle wann ich was machen möchte.

Wenn du zu einem bestehenden Projekt etwas beisteuern möchtest, dann erstellst du einen Fork eigentlich nur um diese Änderung zu machen und dann in das Ursprungsprojekt zurück zuführen.

Wichtig ist, dass du die Zusammenhänge zwischen den Verzeichnissen lokal, origin und upstream verstehst.

In dieser Lektion zeige ich dir mit welchem Button du einen Fork erstellen kannst und wie du erkennst in welchem Projekt du dich gerade befindest.

Für Git ist ein Fork ein ganz normales Verzeichnis. Daher kannst du es in Visual Studio auch einfach klonen. Damit unterscheidet es sich eigentlich nicht von dem Ursprungsverzeichnis. Einen Unterschied merkst du erst dann, wenn du Änderungen die du lokal gemacht hast wieder in das remote-Verzeichnis (bei GitHub) zurück laden willst.

Wichtig ist, dass wenn du beide Verzeichnis bei dir lokal geklont hast, dass du sie auch eindeutig auseinander halten kannst.

Als upstream wird das Verzeichnis bezeichnet, von dem du den Fork erstellt hast. Damit kannst du Änderungen, die in der Zeit am Original-Verzeichnis gemacht wurden, in deinen Fork holen. Insbesondere, wenn du einen Pull Request erstellen willst, ist dies ein wichtiger Schritt.

Wichtig ist, dass du den Unterschied zwischen Origin und Upstream verstehst. Wenn du deinen Clone eines Forks von GitHub auf deinem lokalen Entwicklungsrechner erstellst, hat dieser automatisch ein remote mit dem Namen "Origin". Dieser remote zeigt auf den Fork in DEINEM GitHub-Account.

Um nun deinen Fork mit dem Verzeichnis zu synchronisieren, von dem du den Fork erstellt hast, brauchst du den remote mit dem Namen "Upstream". Diesen kannst du dir ganz einfach selber anlegen.

Öffentliche Projekte auf GitHub sind üblicherweise so aufgebaut, dass es einen oder ein Team von Entwicklern gibt und diese können Änderung an dem Projekt vornehmen. Um nun aber der gesamten Community die Möglichkeit zu geben einen Beitrag zu machen, wurden Pull Requests eingeführt.

Dabei handelt es sich letztlich nur um eine Mail, in der jemand aus der Community darum bittet seine Änderungen in das vom Entwickler gepflegte Git-Verzeichnis zu integrieren. Über diesen "Umweg" wird sichergestellt, dass der verantwortliche Entwickler bzw. das Team die letzte Entscheidung über Änderungen hat.

Es ist letztlich nur ein Button, den du bedienen musst: "Compare & Pull". Konzeptionell und auch Inhaltlich steckt jedoch noch einiges mehr dahinter. Was genau erkläre ich dir in dieser Lektion.

Erstelle einen PullRequest für das Projekt https://github.com/LMStudent/hallo-github

Wie schon zu Anfang erwähnt, kannst du Pull Requests nicht nur bei Open Sourcen Projekten verwenden, sondern auch innerhalb deines Teams. Dabei ist es natürlich egal, ob du an einem öffentlichen oder privaten Projekt arbeitest.

In dieser Lektion zeige ich dir, wie du Änderungen in einem Branch auf GitHub veröffentlichst und dann deine Kollegen (Collaborator im Projekt) um Stellungnahme bzw. Code Review fragst und letztlich die Änderungen dann in den master Branch übernimmst.

Du brauchst nicht alle Branches und Forks behalten, die du für einen Pull Request erstellt hast. Um dein Verzeichnis bzw. dein Account möglichst sauber zu halten, macht es Sinn, dass du Branches und Forks löscht, wenn alle Änderungen aus einem Pull Request übernommen wurden.

Ich erstelle ein PullRequest für dein Projekt und du übst das Review und die Integration der Änderung in dein Projekt.

Erstelle eine GitHub-Page für deinen Account basierend auf dem Theme https://github.com/mmistakes/minimal-mistakes

Es gibt immer mal wieder Fälle in denen du einfach nicht erst deine IDE oder Editor bemühen musst bzw. möchtest. Wenn du beispielsweise an der Dokumentation eine kleine Änderung machst, dann kannst du das auch direkt online auf der Oberfläche (GitHub.com) machen.

In dieser Lektion zeige ich dir anhand eines Beispiels wie das geht.

Neben dem Editieren gibt es noch weitere Funktionalitäten die dir GitHub auf Dateien anbietet. Besonders hilfreich sind "Raw" und History, aber auch "Blame" kann sehr interessant sein.

Ich bin der Ansicht, dass die Stärke von Git darin liegt, dass man ein detailliertes Log über alle Änderungen hat. In großen Projekten führt dies allerdings manchmal dazu, dass die Historien extrem groß wird.

Daher gibt es beim Pull Request die Möglichkeit, dass alle Commits, die du für einen Pull Request gemacht hast zu einem Commit zusammen gefasst werden. Dies wird auch Merge Squashing genannt.

In dieser Lektion zeige ich dir wie das geht.

LGTM steht für "Looks good to me". Es wird auf GitHub sehr häufig verwendet. Einige Projekte definieren sogar, dass ein Pull-Request mindestens ein (oder 2, oder 3, ...) LGTMs braucht, bevor er übernommen werden darf.

Das ganze wird als sign-off bezeichnet. Es geht darum, dass wenigstens ein paar der verantwortlichen Entwickler deine Änderungen angesehen haben und sagen, dass alles okay ist.

Auf GitHub gibt es einen eigenen Bereich für Releases. Dieser wird "gesteuert" über Tags die du in Git setzt. In dieser Lektion zeige ich dir wie du das machst, wie du sie aus Visual Studio nach GitHub bekommst und wie du dann in GitHub das ganze überarbeiten kannst.

Gerade wenn du dich an einem Projekt beteiligst, oder ein anderes Projekt (z.B. eine Bibliothek) von GitHub in deinem Quellcode verwendest, ist es gut, wenn du über den Projektverlauf auf dem laufendem bleibst. Dafür gibt es die "Watch" Funktionalität bei GitHub.

Das ist so ähnlich wie dem "Folgen" auf Facebook oder Twitter. In deiner "Timeline" siehst du dann alle wesentlichen Änderungen die an dem Projekt welches du "beobachtest" gemacht werden. Dazu gehören:

• Issue erstellen - Insbesondere, wenn Leute einen neuen Fehler melden, dann ist das häufig für dich interessant. So kannst du schnell feststellen, ob der Fehler dich auch betrifft.
• Issue kommentieren - Du wirst über alle Kommentare zu einem Issue informiert. Bei einem Fehler erfährst du somit sofort, wenn jemand einen Workaround gefunden hat.
• Pull Request erstellen - Wenn jemand eine neue Funktionalität oder eine Fehlerbehebung vorschlägt, ist das natürlich auch wichtig.
• und einige weitere

Wichtig ist natürlich, dass die ganzen Nachrichten dich nicht stören. Daher gibt es verschiedene Einstellungen, mit denen du beeinflussen kannst, wie du benachrichtigt wirst.