Wie man Git und Github benutzt
Das Wichtigste zuerst: Git und Github sind zwei verschiedene Softwares. Wir sollten uns daher also zuerst einmal damit befassen, was sie sind und wie sie funktionieren!
Versionsverwaltung
Git ist ein Open-Source-Tool zur Versionsverwaltung, das im Jahr 2005 entwickelt wurde. Den Begriff “Versionskontrolle” findet man auch unter dem Begriff “Source-Control”. Versionsverwaltung ist ein System, das Änderungen an einer Datei über die Zeit verfolgt und aufzeichnet. Es ist das Gehirn hinter dem Arbeiten aus dem Homeoffice oder von unterwegs. Es ermöglicht einem Team von Entwicklern, ihren Quellcode einzusetzen und zu verwalten, egal wo auf der Welt sie sich befinden.
Die Vorteile der Versionsverwaltung mit Git:
- Es schafft ein verteiltes System zur Codeverwaltung.
- Es erstellt Snapshots des aktuellen Zustands eines Codes.
- Es ermöglicht einem Team von Entwicklern, effizient und intelligent zusammenzuarbeiten.
- Es erzeugt Zweige, die mehrere Arbeitsströme von verschiedenen Entwicklern, unabhängig voneinander, festhalten. Diese Zweige können zu einer einzigen Code-Datei zusammengeführt werden.
- Änderungen am Code sind nachvollziehbar, wer ihn geändert hat, wann er geändert wurde und welche Versionen es vorher gab.
- Es ist betriebssystem- und sprachunabhängig. Jeder Entwickler kann von jedem System und mit jeder Sprache an Git arbeiten.
Git ist natürlich nicht die einzige Versionsverwaltung. Andere Versionsverwaltungssysteme sind CVS, Bazaar und SNV.
Github
Github wird oft als Synonym für Git verwendet. Hier muss man jedoch aufpassen. Github ist nämlich ein Cloud-basierter Hosting-Service, der Tools zur Integration mit Git herstellt. Github hilft Entwicklern, ihre Repositories zu verwalten.
Während Git lokal auf dem System installiert wird, ist Github Cloud-basiert. Git verwendet eine Reihe von Befehlen, während Github eine freundliche GUI und ein Benutzerverwaltungssystem hat.
Wie sind Git und Github miteinander verbunden?
Git verwaltet den Quellcode, der dann in ein Git Repo verschoben wird, während Github als Ort zum Hochladen von Kopien eines Git Repo dient. Es ist sehr wohl möglich, mit Git ohne Github zu arbeiten, aber nicht möglich, mit Github ohne Git zu arbeiten. Konzepte von Git und Github.
Wichtige Konzepte in Git und Github
Repository
Repository - oder kurz Repo - ist ein sehr gebräuchlicher Begriff in Git und Github. Ein Repo ist eine Sammlung von Dateien und Ordnern, die zu einem Projekt gehören, zusammen mit den Dateiversionen, der Historie und den Mitwirkenden. Github ist wie ein Speicherort für Repos. Repos können in Git erstellt und aktualisiert werden und mit dem Push-Befehl nach Github geschoben werden. Auf Github werden Repos über das Webinterface erstellt und Dateien dorthin hochgeladen. Jedes Repos hat seinen eigenen Repos-Namen. Operationen wie Pull Requests und Forking können auf Github Repos durchgeführt werden, während Cloning auf Git Repos durchgeführt wird.
Git Branches
Branches werden erstellt, um Entwicklern die Möglichkeit zu geben, an einem Feature oder einem Teil der Software zu arbeiten und den Code zu ändern, ohne das gesamte Projekt zu verändern. Mit dem Befehl git branch kann ein Entwickler Branches erstellen, umbenennen, bearbeiten und löschen.
Ein Master-Branch ist der Standard- oder Hauptzweig eines Repo. Jeder andere Branch wird für die Produktion oder das Deployment in den Master-Branch zusammengeführt. Der Master ist technisch gesehen die Arbeitsversion des Projekts.
Um einen Branch zum Master zusammenzuführen, darf der vorgestellte Branch keinen Konflikt mit dem Master haben.
Related Articles
Merge und Rebase
Merge- und Rebase-Befehle werden verwendet, um Änderungen von einem Branch in einen anderen zu integrieren. Sie unterscheiden sich darin, wie dies erreicht wird.
Merge verwendet den Befehl:
$ git checkout feature git merge masterOder etwas kürzer/p>
$ git merge feature masterWenn ein Entwickler merge verwendet, wird der feature Branch zusammen mit den Commits und der Historie der Branch-Dateien zum Master zusammengeführt.
Rebase verwendet den Befehl
$ git checkout feature git rebase masterRebase integriert einen Branch in einen Master mit einem einzigen Patch. Im Gegensatz zu merge entfernt es die Commit-Historie des vorgestellten Branches und schreibt dessen gesamte Historie neu. Rebase überträgt nur die abgeschlossene Arbeit aus dem featured Branch in den Branch und eliminiert die unerwünschte History.
Obwohl sowohl Merge als auch Rebase die gleiche Kernfunktionalität haben - Zweige zu integrieren, sind sie auch unterschiedlich. Merging bewahrt die Historie des Branches, Rebase nicht.
Merging eignet sich am besten für öffentliche und geteilte Branches, wo viele Entwickler an einem Branch arbeiten. Rebasing ist am besten für einen sauberen, linearen Commit. Es verursacht Probleme mit anderen Branches, wenn es auf einem öffentlichen Branch verwendet wird, denn wenn ein Branch rebased wird, weicht die Geschichte des Branches von der aller anderen ab. Diese Divergenz schafft Probleme.
Pull Requests
Pull Requests werden nicht nur von Entwicklern in einem Team verwendet. In Open-Source-Software, wo der Code öffentlich für Modifikationen und Änderungen zugänglich ist, senden Mitwirkende aus der ganzen Welt ihre Änderungen mit einem Pull-Request ein.
Nachdem du einen Pull Request initiiert hast, wirst du aufgefordert, deine Änderungen zwischen den Branches und dem Master zu vergleichen. Einen Pull Request zu initiieren bedeutet auch, mit den anderen Entwicklern zusammenzuarbeiten, um die vorgeschlagenen Änderungen zu überprüfen, bevor dein Commit zusammengeführt wird.
Ein Pull Request hat drei Stati,
Open:: Dies ist ein Pull Request, der noch nicht bearbeitet wurde, in der Schwebe ist oder Änderungen benötigt.
Closed: Ein abgelehnter Pull Request.
Merged: Ein Pull Request, der mit dem ursprünglichen Code zusammengeführt wurde.
Fork und Clone
Forking wird auf Github durchgeführt, während Git Clone auf Git mit dem Befehl git clone durchgeführt wird. Git clone ist ein Befehl, der den Code in einem entfernten Repository auf einen lokalen Rechner herunterlädt, normalerweise den Computer des Entwicklers. Ein geklontes Repository nimmt die Url des ursprünglichen Repos und den Namen des Repos.
ssh://git@github.com/<username>/<repository-name>.gitDie Verwendung von git clone ist wie die Verwendung der Kopierfunktion in Word-Dokumenten. Es gibt dir die exakte Kopie des Inhalts des Repo, wie zu der Zeit, als der Clone initiiert wurde. Änderungen, die an einem geklonten Repo auf einer Maschine gemacht werden, können mit Upstream-Befehlen direkt in das ursprüngliche Repo gepusht werden.
Das Forken eines Repos ist das Erstellen einer Replik eines Repos auf einem anderen Account zu deinem persönlichen Account. Das Forking nimmt die Inhalte, Commits, Branches und Releases des Original-Repos mit zu dir.
Es gibt eine Brücke zwischen dem geforkten Repo und dem originalen Repo und dies erlaubt einem Entwickler an einem Code zu arbeiten, als wäre es sein eigener, ohne den originalen Code zu beeinflussen.
Forking ist in der Open-Source-Welt weit verbreitet, wenn ein Entwickler zu einem Code beitragen möchte. Es funktioniert neben Pull Requests, um Beiträge zu leisten.
Um ein Forked Repo zu identifizieren, werden die Url und der Name des Forked Repo mit dem Original Repo verlinkt.
Befehle in Git
git init
Dieser Befehl initialisiert ein neues lokales Git Repository. Der Repo-Name wird direkt nach dem Befehl hinzugefügt.
$ git init <repo name>git commit
Dieser Befehl speichert Snapshots der Arbeitsversion eines Projekts. Er tut dies, indem er alle Dateien in das Repository überträgt. Du kannst commit nur verwenden, nachdem du die Dateien mit git add ins Repository gestellt hast.
Commits werden normalerweise mit einer Commit-Nachricht hinzugefügt.
$ git commit -m "Commit message goes here"git add
Hiermit wird eine Datei bereitgestellt, damit sie an das Repository übergeben werden kann. Sie können auf drei Arten bereitstellen.
- git add * fügt alle Dateien, Ordner und Unterordner in einem Verzeichnis hinzu, mit Ausnahme von Dateien, die mit einem Punkt wie .gitignore beginnen.
- git add <filename> fügt nur die Datei hinzu, die mit dem Dateinamen angegeben wurde.
- git add . fügt alle Dateien, Ordner und Unterordner in einem Verzeichnis hinzu, einschließlich der Dateien, die mit einem Punkt wie .gitignore beginnen.
$ git add *git config
Dieser Befehl erlaubt es dir, git mitzuteilen, wer du bist. Du kannst deinen Namen und deine E-Mail hinzufügen.
$ git config --global user.name "Your name"
$ git config --global user.email "Youremail@email.com"git status
Dieser Befehl zeigt den Status eines Branches an. Die Verwendung dieses Befehls sagt uns, ob es ungetrackte, staged oder unstaged Dateien gibt. Es lässt uns wissen, ob es Dateien zum Committen, Pushen oder Pullen gibt und ob ein Branch aktuell ist.
$ git status git checkout
Dieser Befehl wird verwendet, um von einem Branch zu einem anderen zu wechseln. Wir können ihn auch zum Auschecken von Commits und Dateien verwenden. Es gibt zwei Regeln für die Verwendung von git checkout.
- Eine Branch muss in der lokalen Version existieren
- Änderungen im aktuellen Branch müssen vor dem Auschecken in den Stage oder Commit gebracht werden
$ git checkout <name-of-branch> git pull
Dieser Befehl holt und lädt Inhalte von einem entfernten Repo herunter und aktualisiert das lokale Repo mit den heruntergeladenen Inhalten.
$ git pull <remote repo> git push
Dieser Befehl pusht übertragene Änderungen aus einem lokalen Branch in ein anderes Repository.
$ git push [variable name] [branch] git clone
Mit diesem Befehl können wir den Quellcode aus einem entfernten Repository auf einen lokalen Rechner herunterladen. Er erstellt eine Kopie dieses Repos auf dem lokalen Rechner.
$ git clone <url-of-remote-repositiory> git merge
Dieser Befehl führt Änderungen von zwei Branches zusammen, normalerweise von einem Feature Branch zu einem Master.
$ git merge <branch name> git branch
Dieser Befehl erstellt einen Branch, der es den Entwicklern erlaubt, gleichzeitig an einem Projekt zu arbeiten, ohne jedoch den Haupt-Branch zu berühren, bis sie die Freigabe zum Zusammenführen erhalten.
$ git branch <branch name> git revert
Dieser Befehl ist eine Sicherheitsmethode, um Änderungen an einem Branch rückgängig zu machen. Git revert gilt als sicherer als die Verwendung von git reset. Um eine bestimmte Aktion oder einen bestimmten Commit rückgängig zu machen, verwenden wir den Hashcode oder die Commit-ID neben dem Commit, den wir rückgängig machen möchten.
$ git revert <commit id> Warum ist Github für Git und Entwickler wichtig?
Github bietet viele Tools für die Zusammenarbeit, die das Arbeiten mit Git einfacher machen. Git alleine zu benutzen kann ziemlich frustrierend sein. Es hat kein richtiges Interface, nur Befehle. Github bietet dieses Interface zusammen mit anderen Werkzeugen, die Entwickler benötigen.
Github erlaubt es Entwicklern, bestimmte Rechte für ein Repo zu vergeben, z.B. bestimmten Benutzern zu erlauben, frei in ein Repo zu pushen.
Github hat auch eine “Issues”-Funktion für Repos, die es dem Team erlaubt, Bugs im Code zu verfolgen. Die Leichtigkeit, mit der Entwickler ein Repo aufspalten und zu ihm beitragen können, kann nicht hoch genug eingeschätzt werden.
Github bietet seine eigenen Socials, die es Profilen erlauben, sich gegenseitig zu folgen oder Repositories zu beobachten.
Zu guter Letzt enthält Github auch eine Art Lebenslauf des Entwicklers. Wenn du wissen willst, wie aktiv ein Entwickler ist, was er bisher gemacht hat und an welchen Projekten er gearbeitet hat, ist seine Github-Seite der richtige Ort.
