Wenn ein Softwareentwickler bzw. Programmierer an seinem Quellcode Änderungen vornimmt, ist eine sogenannte Versionskontrolle notwendig. Denn stell Dir mal vor, es soll ein neues Feature implementiert werden. Das kann beispielsweise ein Button in einer mobilen App sein. Hier wäre es nicht klug, "direkt am offenen Herzen zu operieren". Damit meine ich, dass es nicht notwendig ist, den "offiziellen" Softwarecode zu bearbeiten, sondern nur einen Teil davon.
Und damit kommen die beiden Begriffe Verzweigungen und Zusammenführungen ins Spiel.
Wenn der Entwickler von Verzweigungen spricht, dann meint er, dass er den Quellcode dupliziert. Und schon hast Du einen weiteren Begriff kennengelernt: Repository (oder auch abgekürzt liebevoll Repo genannt 😀). Damit kann der Entwickler Änderungen an dem Quellcode vornehmen, ohne gleich den gesamten "offiziellen" Quellcode zu verändern /bearbeiten. Nach der Änderung kann der Entwickler nochmals seinen Quellcode testen, um beispielsweise zu überprüfen, dass sich kein Softwarefehler eingeschlichen hat. Wenn alles gut läuft dann kann er die Änderung in den ursprünglichen Code einbinden.
Und sollte mal etwas nicht gepasst haben: Selbstverständlich können alle Änderungen wieder rückgängig gemacht werden.
An einem Softwareprojekt arbeiten in der Regel hunderte von Programmieren manchmal sogar tausende. Stell Dir jetzt vor, jemand müsste den ganzen Quellcode jetzt irgendwo pflegen und lagern. Diese Person würde die Arbeitsergebnisse außerdem noch zusammenführen müssen. Bei einem größeren Softwareprojekt würde diese Person ausschließlich damit beauftragt werden, die Softwarecodes zusammenzuführen, zu pflegen und müsste den Code fortlaufend aktualisieren.
Diese Tätigkeit lässt sich aber auch mit einer Versionsverwaltung wie Git aktualisieren.
Das bedeutet: Sämtliche Änderungen von allen Autoren werden an einem zentralen Ort gespeichert. Hat ein Entwickler also eine Änderung an einem Code vorgenommen - z.B. einen neuen Button für eine mobile App entwickelt - kann das ganze Entwicklerteam diese Änderung zentral pflegen.
Die Oberfläche von Github mag den einen oder anderen Neuling abschrecken. Jedoch ist die Oberfläche von Github so benutzerfreundlich, dass man es nicht nur für das Verwalten von Projekten verwenden kann, sondern beispielsweise auch für:
Auch ich habe ein Repository, der öffentlich zugänglich ist. Dort findest Du alles Wissenswerte über Active Sourcing und IT Recruiting. Dort habe ich beispielsweise u.a. Links hinterlegt, nützliche Gruppen zum Thema Active Sourcing zusammen gestellt oder auch hilfreiche Extensions für Deine Arbeit abgelegt.
In Github findest Du mich unter: TechSourcer/Recruiting-Stuff: This is all about Recruiting and Sourcing (github.com)
Im nachfolgenden werden wir uns mal ein paar Beispiele anschauen, welche Wörter relevant sind und die Du als Github Neuling einmal gehört haben solltest - es klingt etwas kompliziert aber ich versuche es an dieser Stelle einfach zu halten:
Repository (oder auch Repo genannt)
Eigentlich ist ein Repository nichts anderes als ein Projekt. Hier werden die Dateien für ein Softwareprojekt in einem Repository abgelegt.
Ein Repository habt ihr ja bereits kennengelernt und zwar das obige. Wenn ihr mal auf der Github Seite unterwegs sein solltet, dann findet ihr z.B. in der "User" Übersicht die zugehörigen Repositories - in meinem Falle habe ich z.B. acht Repositories.
Commit
Damit werden alle Änderungen für ein Projekt nachvollziehbar gemacht. Jeder Commit hat übrigens eine eigene ID und diese wird als SHA oder Hash bezeichnet. Damit kann man folgende Dinge identifizieren:
Macht jetzt ein User eine Commit Änderung, dann musst der auch erläutern, was er geändert hat.
Pull-Request
Stell Dir vor es gibt einen Fehler in der Software. Diesen nennt man auch "Bug" oder "Softwarebug". Wenn der Bug nun behoben wird (man spricht von einem Fix) und der Entwickler möchte, dass seine Änderung in das ursprüngliche Projekt berücksichtigt wird. Also jemand bittet drum, dass seine Änderungen (in diesem Falle der Softwarefix) berücksichtigt wird.
Pull
Wenn Du das Prinzip des Pull-Request verstanden hast, wird der Pull Begriff auch einleuchtend sein. Bedeutet nichts anderes, als dass sämtliche Änderungen, die in einem "Repo" vorgenommen wurden (z.B. Softwarefix) einfach übernommen werden.
Fork
Lt. Github kannst Du Änderungen an einem Repository vornehmen, ohne dass sich dies auf das ursprüngliche Repository auswirkt. Wenn wir vom ursprünglichen Repository sprechen, dann sprechen wir auch von einem sogenannten "Upstreamrepository".* Und jetzt wird es kompliziert - lt. Github - ich zitiere mal "Nachdem Du ein Repository geforkt hast, kannst Du Updates aus dem Upstreamrepository abrufen, um Deinen Fork auf dem neuesten Stand zu halten."*
Bedeutet nichts anders wie: Man hat z.B. ein Tic-Tac Toe Spiel. Und dieses Tic-Tac Toe Spiel ist in einem Repository abgelegt. Du nimmst das, veränderst es - weil beispielsweise die Kreuze Lila sein sollen, die Kreise Rosa und Du einen dunklen Hintergrundmodus hast - was auch immer. Du kannst das Projekt also privat weiterentwickeln und wieder dem ursprünglichen Projekt zuführen. Hier machst Du aber dann einen Pull-Request oder machst einfach eine eigene Variante auf.
Es gibt natürlich auch Open Source Projekte, wo Du dann mehrfach neue Ideen oder Anregungen durchspielen kannst, bevor diese dann in den ursprünglichen Repository (Upstreamrepository) wieder aufgenommen werden.
Branch
Eine Branch ist nichts anderes als ein "Ast" oder ein "Zweig" eines Repositories. Bedeutet. dass wenn Du ein Repository hast, dann kann es mehrere Versionen einer Software geben. Zum Beispiel eine Version für die Produktivumgebung (oder auch Live Umgebung genannt) und eine sogenannte Beta-Version (eine Beta Version ist z.B. etwas was sich noch in der Entwicklungsphase befindet - z.B. ein unfertiges Tetris Spiel).
Und in Github sieht eine Branch tatsächlich auch aus wie ein Ast (s.u.)
Maintainer
Das einfachste an dem ganzen Kram hier: Die Verantwortlichen der Repositories.
*Quelle: Informationen zu Forks - GitHub-Dokumentation
Jetzt bleibt zu hoffen, dass Dich die ganzen Definitionen und Begriffe nicht allzu sehr verwirrt haben. 🙃
Fakt ist: Github ist ein Muss für jeden Active Sourcer - daher solltest Du zumindest die Definitionen kennen. Und das Beste an Github ist:
Es ist eine Plattform für Entwickler und für uns Sourcer ist es eine Goldgrube. Github sollte, wenn Du nach IT Experten/innen suchen solltest , eine Deiner ersten Anlaufstellen im Active Sourcing sein.
Und jetzt fragst Du Dich: "Reicht denn Linkedin nicht aus für die Suche nach IT-Experten?" Eigentlich schon. Aber wenn wir in der Linkedin Bubble bleiben, dann gilt doch der Satz: "Suchst Du nur Kandidaten auf Linkedin - findest Du auch nur Kandidaten auf Linkedin" - da ist etwas wahres dran, nicht wahr?
Selbstverständlich gilt das Credo auch umgekehrt. "Suchst Du nur Kandidaten auf Github, findest Du auch nur Kandidaten auf Github". Daher sollte ein Talent Sourcer sich nicht nur auf eine Plattform beschränken, sondern seine mehrere "Sourcing" Pfade ausprobieren.
"Problematisch" bei Github ist, dass Nutzer auch oftmals Phantasienamen verwenden - wie in meinem Falle: TechSourcer und nicht Daniel Böhm. Die meisten Github Nutzer haben jedoch oft weiterführende Links: Sei es zu Twitter, Linkedin, Medium, Stack Overflow - und dort wiederum - kannst Du unter umständen mit etwas Detektivarbeit weitere Informationen über das Profil erhalten.
Aus meiner Perspektive ist das Active Sourcing in Github ein absolutes Muß Kriterium, wenn Du nach speziellen IT-Profilen suchst. In meinen Kursen habe ich eine Vielzahl von Tipps und Tricks, um genau diese Kandidaten zu finden. Sprich mich gerne an!
Nein. Denn bei Stack Overflow stellen Entwickler konkrete Fragen zu einem Problem. Ein Problem kann beispielsweise eine Fehlermeldung in dem vom Entwickler erstellten Programmcode sein.
Und andere Nutzern können dann die Frage beantworten. Man kann hier sogar Punkte oder sogenannte Badges erhalten.
Stack Overflow ist quasi eine Mischung aus Wikipedia und einem Fragenportal. In Github hingegen können Nutzer ihren Quellcode bzw. Programmcode hochladen und es mit anderen gemeinsam bearbeiten bzw. teilen. Man spricht hier auch von "Social Coding".
Mehr Informationen - auch zu Stack Overflow - gibt es übrigens in dem Advanced Kurs. Sprich mich gern darauf an!
Na klar! Beispielsweise geht das über die x-Ray Suche. Viele weitere Tricks zeige ich Dir übrigens in meinen Videos. Daneben finden wir noch weitere interessante Plattformen.
Ja. Die Videos sind im Advanced Kurs verfügbar (Video on Demand). Dort wird alles Schritt für Schritt erklärt und ist auch somit für einen Nicht-ITler nachvollziehbar. Mit vielen Praxisbeispielen, so dass für Dich hier der "Aha" Effekt kommen wird.
Github ist ausschließlich im Advanced Kurs abrufbar.