Freifunk Gera-Greiz

Warum sollten Versicherungen abgeschlossen werden

Bisher haben wir als Verein nur ein sehr überschaubares Inventar.

Die Geräte liegen an verschiedenen Stellen bei Mitgliedern verteilt zu Hause herum.

Sollten wir einen Hackerspace bekommen, der auch als Lager genutzt wird, dann sammeln wir unsere Schätze an einem zentralen Platz, der nicht mehr durch eine private Hausratversicherung abgedeckt ist. (Falls dort auch Privateigentum von Mitgliedern liegt, sieht das dafür ggf. anders aus. Der Begriff ist dann IMHO "ausgelagerter Hausrat".)

Wenn wir als Verein Dinge bei Dritten erledigen und dabei Schaden verursachen, ist der Verein haftbar. Wenn keine Versicherung vorliegt, haftet der Vorstand direkt.

Bisher halten sich die bekannten Schäden noch in Grenzen, bei zukünftigen vereinsgetriebenen Standorten (bspw. Leibnizturm), halte ich das Risiko aber für deutlich größer und damit versicherungswürdig.

Davon abgesehen, ist für (viele) Bereitsteller von Standorten eine Versicherung des Installateurs/Betreibers/Fremdeigentümers Pflicht.

Wenn ein Vereins-/Community-Mitglied beim Basteln vom Dach fällt, greifen ggf. private Versicherungen aus Ausschlussgründen nicht.

Wenn wir ein Vereinsevent durchführen und dabei Dritte zu Schaden kommen ("Kind fällt vom Freifunk-Karussel"), sind wir als Verein haftbar.

Ich nehme hier keine Unterscheidung nach Verein und Community vor!

Das ist Absicht. Da es den Verein gibt, erscheint es mir schwer zu argumentieren, dass wir "nur" als Community irgendetwas gebaut/organisiert haben. Das klingt sehr danach, dass man Ausschlusskriterien vermeiden will.

Welche Versicherungen sind notwendig

  • Haftpflicht (Wir sind schuld und andere haben den Schaden.)
  • Unfall (Wir fallen vom Dach. Unser Schaden.)
    • Die gesetzliche UV gilt unter Umständen für ehrenamtliche Tätigkeiten. (Kurz: Sobald wir für eine Kommune oder Kirche etwas aufbauen.)
  • Hausrat (Der böse Hagelblitz zerstört unser Eigentum im geschützten Raum. Unser Schaden.)
  • Veranstalter (Andere kriegen bei einem Fest eine Antenne ins Auge. Schaden Dritter.)
  • Diebstahl/Elektronik (Wieder der böse Hagelblitz, aber diesmal hängt die Antenne am Mast. Unser Schaden.)
  • Vermögensschaden-Haftpflicht (Vereinsschaden, Absicherung des Vorstandes)

Angebote

Versicherungsangebote
Versicherung Haftpflicht Unfall Hausrat Veranstalter Sonstiges
Gothaer Versicherung - Björn Hauke vom 21.09.2017

201,79 EUR (+59,50 EUR für "Meldemast")

Die eigentliche Versicherung beträgt nur wenige Euro. Es gibt aber eine Mindesthöhe.

156,69 EUR (14 Mitglieder)

9,90 EUR/Mitglied

    

"Elektronikversicherung"

Das umfasst Schäden durch Diebstahl, Sabotage usw.

Der Preis ist "hoch".
LVM          
HDI Compact vom 20.02.2017 178,44 EUR (12,76% der Gesamtsumme) 1220,04 EUR (87,24%)   als Firmenversicherung angeboten  

Stiftung DEUTSCHES EHRENAMT

(online)

 299,00 EUR (Vereinsschutzbrief)     (Vereinsschutzbrief)  

 

Details
Kategorie: Allgemein

Wir stellen jetzt auf unseren Servern auf IPv6 um und bieten damit jetzt auch volle IPv6-Unterstützung an. Weiterhin bleibt natürlich auch IPv4 aktiv. [Stand März 2016]

Was ist IPv6?

IPv6 ist ein Internetprotokoll, welches das derzeit verbreitete IPv4 schrittweise ablösen und ersetzen soll. IPv6 bietet einen um einiges größeren Adressraum und erlaubt so beispielsweise jedem Endgerät mindestens eine eigene Adresse zuzuordnen. Dadurch ist es möglich, dass auch jedes Gerät direkt aus dem Internet erreichbar ist.

Fakt am Rande: Durch IPv6 vergrößert sich der Adressraum von 2³² (≈ 4,3 Milliarden = 4,3·10⁹) Adressen (IPv4) auf 2¹²⁸ (≈ 340 Sextillionen = 3,4·10³⁸) Adressen (IPv6). [¹]

Was ändert sich für mich durch IPv6?

Grundsätzlich ändert sich erst einmal nichts. Dadurch, dass jetzt jedes Gerät eine eigene Adresse bekommt, sind z.B. keine Portweiterleitungen im Router mehr notwendig. Außerdem erhöht sich damit die Erreichbarkeit der Geräte, da Dienste wie NAT und DHCP eingespart werden können.

Wie früher wird der Client nicht mehr direkt vom Router geschützt da kein NAT mehr genutzt wird, daher muss jedes Gerät sich selbst schützen.

Wichtig für alle die interne Dienste (z.B. mit einem Server, Offloader, Raspberry Pi, Fernseher, Set-Top-Box, Webcam, ...) anbieten: Der Dienst ist damit auch von außen (also vom Internet aus) erreichbar!

Was muss ich tun damit IPv6 bei mir funktioniert?

Unter den aktuellen Systemen funktioniert es von Haus aus schon. Bei älteren Betriebssysteme kann es notwendig sein, dass zusätzliche Treiber benötigt werden – allerdings ist es nicht zu empfehlen so alte Software zu verwenden.

Was muss ich bei IPv6 beachten?

Da jedes Gerät von außen erreichbar ist und eine eindeutige IPv6-Adresse (welche unter anderem die MAC-Adresse des Netzwerkinterface enthält) erhält, ist es möglich den Benutzer zu identifizieren und damit nachzuverfolgen (tracken). Damit aber die Privatsphäre und Sicherheit erhalten bleibt, gibt es unter IPv6 die so genannte ‘Privacy Extension’ [²], die in regelmäßigen Abständen für neue Verbindungen per Software-Zufall eine neue IPv6-Adresse wählt. Die Privacy Extension ist bei den meisten aktuellen Betriebssystemen bereits standardmäßig aktiviert.

Um die Sicherheit und Privatsphäre zu schützen haben wir eine kleine Checkliste:

  • IPv6 Privacy Extension aktivieren [³]
    • Windows: ab Windows XP aktiviert
    • Mac OS: ab 10.7 aktiviert
    • Linux: abhängig von der Distribution
      • Ubuntu: ab 12.04 aktiviert
      • Debian / Raspbian: deaktiviert
      • Gentoo: deaktiviert
    • iOS: ab iOS 4.3 aktiviert
    • Android: deaktiviert
    • Weiter Informationen zum Aktivieren: http://heise.de/-1204783
  • Firewall aktivieren
  • weiterhin auf HTTPS und aktuelle Software achten

Trivia

  • Jedes Interface gibt sich mit Hilfe der Autokonfiguration von alleine eine IPv6-Adresse welche mit 'fe80:' beginnt (z.B.: fe80::44:8ff:fe0f:8734/64). Diese ist nur im aktuellen Netzwerk verfügbar und ist auch nicht von der Privacy Extension betroffen. Sie dient dazu, dass sich die Netzwerkteilnehmer intern bereits verständigen können.
  • Statt DHCP werden per ICMPv6 sogenannte Router Advertisements verschickt, welche die Konfiguration für das jeweilige Netz beinhalten. Es gibt zwar auch DHCPv6, dieses ist aber nicht mehr zwingend notwendig.
  • Im Gegensatz zu DHCP (bei IPv4) können über Router Advertisement mehrere Router oder Gateways existieren. Das Gerät wählt dann selbst den besten Router aus.
  • Mit dem Router Advertisement kann über den Zusatz RDNSS/DNSSL auch der DNS-Server mitgeliefert werden, das wird aber derzeit nicht von allen Betriebssystemen unterstützt. Dadurch ist aktuell DHCPv6 bei reinen IPv6-Netzwerken zwingend notwendig. (z.B. Microsoft Windows)
  • DNS-Anfragen für IPv6 können auch über IPv4 erledigt werden und benötigen keinen extra DNS-Server.
  • Bei IPv6 wurde die ARP-Auflösung durch das “Neighbor Discovery Protocol” ersetzt.
  • Der von IPv4 bekannte Broadcast, ist in IPv6-Netzen nur noch über Multicast möglich.
  • Aktuell wird nur der IPv6-Adressbereich 2000::/3 für das Internet verwendet.
  • Eine IPv6-Adresse besteht aus 128-Bit (eine IPv4 Adresse hat zum Vergleich nur 32-Bit) und wird in zwei Teile geteilt. Der erste Teil (64-Bit: Subnetz) wird vom Provider vergeben, die zweiten 64-Bit (Interface-Identifier) beinhalten die MAC-Adresse (bzw. bei der Privacy-Extension einen zufälligen Wert). Dies hat den Vorteil, dass bei einem Providerwechsel der zweite Teil eindeutig bleibt und Roaming (Multihoming) erlaubt.



Sehr informativ ist auch dieses Plakat von IPv6-Handbuch.de: https://www.ipv6-handbuch.de/Plakate/IPv6-Unicast-Adressen

Quellen

[¹] https://de.wikipedia.org/wiki/IPv6

[²] http://www.elektronik-kompendium.de/sites/net/1601271.htm

[³] https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

Details
Kategorie: Allgemein

Bandbreitentests mit iperf auf 2720m Abstand, direkte Sichtverbindung

Knoten 1 (Gera-Der Preis-eV-01) <- 2720m -> Knoten 2 (Gera-Fuchsberg-Link1)

Vorbereitung

opkg update 
opkg install iperf3 -d ram

Messung

root@Gera-Fuchsberg-Link1:~# /tmp/usr/bin/iperf3 -6 -t 60 get-server-output -i 10 -c 2a03:2260:100b:0:6a72:51ff:fe3e:85bc
root@Gera-Der Preis-eV-01:~# /tmp/usr/bin/iperf3 -6 server -i 10

Knoteninformationen

  Gera-Der Preis-eV-01 Gera-Fuchsberg-Link1
cat /lib/gluon/gluon-version v2016.2.6 v2016.2.6
iwinfo 
client0   ESSID: "Freifunk"
          Access Point: 3E:25:F9:4B:7D:B0
          Mode: Master  Channel: 6 (2.437 GHz)
          Tx-Power: 20 dBm  Link Quality: 46/70
          Signal: -64 dBm  Noise: -95 dBm
          Bit Rate: 78.0 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 168C:002E 0777:E0A2 [Ubiquiti NanoStation Loco M2]
          TX power offset: 8 dB
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0


mesh0     ESSID: unknown
          Access Point: 00:00:00:00:00:00
          Mode: Mesh Point  Channel: 6 (2.437 GHz)
          Tx-Power: 20 dBm  Link Quality: 31/70
          Signal: -79 dBm  Noise: -95 dBm
          Bit Rate: 19.5 MBit/s
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 168C:002E 0777:E0A2 [Ubiquiti NanoStation Loco M2]
          TX power offset: 8 dB
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0
 
root@Gera-Fuchsberg-Link1:~# iwinfo
client0   ESSID: "Freifunk"
          Access Point: 6E:E8:DB:C6:20:08
          Mode: Master  Channel: 6 (2.437 GHz)
          Tx-Power: 23 dBm  Link Quality: 55/70
          Signal: -55 dBm  Noise: -95 dBm
          Bit Rate: 58.5 MBit/s
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 168C:002E 0777:E0A2 [Ubiquiti NanoStation Loco M2]
          TX power offset: 8 dB
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0


mesh0     ESSID: unknown
          Access Point: 00:00:00:00:00:00
          Mode: Mesh Point  Channel: 6 (2.437 GHz)
          Tx-Power: 23 dBm  Link Quality: 30/70
          Signal: -80 dBm  Noise: -95 dBm
          Bit Rate: 24.9 MBit/s
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 168C:002E 0777:E0A2 [Ubiquiti NanoStation Loco M2]
          TX power offset: 8 dB
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0
iw dev mesh0 station dump 
Station 06:5a:2d:a8:04:91 (on mesh0)
        inactive time:  0 ms
        rx bytes:       4070392132
        rx packets:     113069972
        tx bytes:       1361406439
        tx packets:     25575821
        tx retries:     10253336
        tx failed:      10297
        signal:         -71 [-79, -72] dBm
        signal avg:     -70 [-79, -71] dBm
        Toffset:        -985469203193 us
        tx bitrate:     39.0 MBit/s MCS 4
        rx bitrate:     28.9 MBit/s MCS 3 short GI
        expected throughput:    16.479Mbps
        mesh llid:      14699
        mesh plid:      10622
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        connected time: 1067296 seconds
Station 6e:e8:db:c6:20:09 (on mesh0)
        inactive time:  40 ms
        rx bytes:       289312060
        rx packets:     95862190
        tx bytes:       2732088153
        tx packets:     22517270
        tx retries:     18688150
        tx failed:      1709
        signal:         -75 [-77, -79] dBm
        signal avg:     -75 [-77, -79] dBm
        Toffset:        660625609305 us
        tx bitrate:     39.0 MBit/s MCS 10
        rx bitrate:     26.0 MBit/s MCS 3
        expected throughput:    8.331Mbps
        mesh llid:      60456
        mesh plid:      64101
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        connected time: 1067296 seconds
Station d2:b7:17:98:e4:01 (on mesh0)
        inactive time:  816280 ms
        rx bytes:       4834
        rx packets:     53
        tx bytes:       2851
        tx packets:     28
        tx retries:     204
        tx failed:      28
        signal:         -84 [-86, -88] dBm
        signal avg:     -83 [-86, -86] dBm
        Toffset:        -67304080741 us
        tx bitrate:     6.5 MBit/s MCS 0
        rx bitrate:     6.5 MBit/s MCS 0
        mesh llid:      6464
        mesh plid:      44927
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      UNKNOWN
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        connected time: 4497 seconds

Station 3e:25:f9:4b:7d:b1 (on mesh0)
        inactive time:  0 ms
        rx bytes:       4222856885
        rx packets:     120559926
        tx bytes:       3893496084
        tx packets:     24134805
        tx retries:     16894807
        tx failed:      3044
        signal:         -76 [-78, -81] dBm
        signal avg:     -76 [-78, -80] dBm
        Toffset:        -660625634204 us
        tx bitrate:     39.0 MBit/s MCS 10
        rx bitrate:     39.0 MBit/s MCS 10
        expected throughput:    21.56Mbps
        mesh llid:      64101
        mesh plid:      60456
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        connected time: 1211819 seconds
Station d2:b7:17:98:e4:01 (on mesh0)
        inactive time:  70 ms
        rx bytes:       1226215409
        rx packets:     9729747
        tx bytes:       36944
        tx packets:     392
        tx retries:     2866
        tx failed:      347
        signal:         -82 [-88, -83] dBm
        signal avg:     -82 [-89, -83] dBm
        Toffset:        -727929702331 us
        tx bitrate:     6.5 MBit/s MCS 0
        rx bitrate:     6.5 MBit/s MCS 0
        expected throughput:    1.921Mbps
        mesh llid:      32246
        mesh plid:      19176
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        connected time: 1034341 seconds
iwinfo mesh0 assoclist 
06:5A:2D:A8:04:91  -73 dBm / -95 dBm (SNR 22)  10 ms ago
        RX: 43.3 MBit/s, MCS 4, 20MHz, short GI     113076142 Pkts.
        TX: 43.3 MBit/s, MCS 10, 20MHz, short GI    25575961 Pkts.


6E:E8:DB:C6:20:09  -76 dBm / -95 dBm (SNR 19)  60 ms ago
        RX: 39.0 MBit/s, MCS 10, 20MHz              95866519 Pkts.
        TX: 14.4 MBit/s, MCS 1, 20MHz, short GI     22517374 Pkts.


D2:B7:17:98:E4:01  -83 dBm / -95 dBm (SNR 12)  901500 ms ago
        RX: unknown                                       54 Pkts.
        TX: 6.5 MBit/s, MCS 0, 20MHz                      28 Pkts.
 
3E:25:F9:4B:7D:B1  -77 dBm / -95 dBm (SNR 18)  10 ms ago
        RX: 14.4 MBit/s, MCS 1, 20MHz, short GI     120564396 Pkts.
        TX: 39.0 MBit/s, MCS 10, 20MHz              24134908 Pkts.


D2:B7:17:98:E4:01  -81 dBm / -95 dBm (SNR 14)  5550 ms ago
        RX: 6.5 MBit/s, MCS 0, 20MHz                 9729895 Pkts.
        TX: 6.5 MBit/s, MCS 0, 20MHz                     392 Pkts.

Testreihe 1: Ubiquiti NanoStation loco M2 – Ubiquiti NanoStation loco M2

root@Gera-Fuchsberg-Link1:~# batctl traceroute 2a03:2260:100b:0:6a72:51ff:fe5e:9b6b
traceroute to 2a03:2260:100b:0:6a72:51ff:fe5e:9b6b (9e:dc:24:40:6a:d3), 50 hops max, 20 byte packets
1: 3e:25:f9:4b:7d:b3  1.324 ms  1.166 ms  0.964 ms
2: 06:5a:2d:a8:04:93  3.367 ms  1.958 ms  2.672 ms
3: 9a:d4:e8:67:39:53  4.418 ms  2.989 ms  3.723 ms
4: de:ad:be:ef:02:03  22.672 ms  21.603 ms  21.663 ms
5: 9e:dc:24:40:6a:d3  65.765 ms  66.589 ms  72.154 ms

 

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  36.9 MBytes  5.16 Mbits/sec   34             sender
[  4]   0.00-60.00  sec  36.8 MBytes  5.15 Mbits/sec                  receiver

 

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  46.0 MBytes  6.43 Mbits/sec   42             sender
[  4]   0.00-60.00  sec  46.0 MBytes  6.43 Mbits/sec                  receiver

 

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  53.7 MBytes  7.50 Mbits/sec   89             sender
[  4]   0.00-60.00  sec  53.6 MBytes  7.50 Mbits/sec                  receiver

Details
Kategorie: Allgemein

Für die Darstellung von Karten und Listen über die Freifunk-Communities und andere Anwendungen, z.B. einen Newsfeed-Aggregator, wurde eine API entwickelt. Um die eigene Community aufzunehmen, erstellt man einfach über ein Web-Formular eine JSON-Datei. Diese wird dann irgendwo auf der eigenen Webseite plaziert. Anschließend wird dazu (URL zur JSON-Datei) ein Eintrag zentral im dafür angelegten GitHub-Repository hinterlegt.

Die Community Gera-Greiz wurde dabei bereits als Metacommunity mit den beiden Communities Gera und Greiz definiert. So ist später einmal eine einfache Trennung möglich. Die beiden Files wurden auf unserer Webseite plaziert:

Die JSON-Files sollten immer aktuell an Veränderungen angepaßt werden. Die meisten Parameter sind relativ statisch, Ausnahme ist die Knotenanzahl. Um diese automatisch anzupassen, wurde das Python-Script ffapi.py in /etc/cron.d/hourly auf dem Portalserver erstellt, welches damit stündlich abgearbeitet wird. Dieses Script liest aus der für die Kartenanzeige sowieso vorhandenen Datei /var/www/localhost/htdocs/meshviewer/data/nodes.json die aktuelle Zahl aktiver Knoten aus. Aus der Vorlage /var/www/localhost/htdocs/Base-api.json werden dann die beiden Dateien /var/www/localhost/htdocs/FreifunkGera-api.json und /var/www/localhost/htdocs/FreifunkGreiz-api.json mit den aktuellen Daten erzeugt.

Details
Kategorie: Allgemein

<>

Einleitung

Als Beispiel für die Versionsverwaltung mittels Git soll im Folgenden die Erstellung eines neuen Firmware-Releases für die Router unserer Knoten beschrieben werden. Der eigentliche Prozess der Firmware-Erstellung ist bereits unter Firmware beschrieben. Demnach wird derzeit ein Standard-Gluon verwendet, nur dessen Konfiguration wird an unsere Community angepaßt. Diese Konfiguration verwalten wir im Repository "site-ffggrz".

Repository-Struktur, Versionierung

Im Repository gibt es neben dem Master-Branch noch je einen Branch für die aus den stabilen Gluon-Releases gebauten stable Firmwares. Der Master-Branch enthält die Konfiguration für die aktuelle Development-Version von Gluon. Daraus erstellen wir ausschließlich experimental Firmware.

Vorbereitungen

Persönlichen Fork erstellen

Da wir nicht direkt unser offizielles Repository ändern wollen, erstellen wir unseren eigenen Fork. Dazu klicken wir als eingeloggter Github-Benutzer im Repository "site-ffggrz" auf den Knopf "Fork" (rechts oben):

Danach werden wir automatisch auf den neu erstellten Fork unter https://github.com//site-ffggrz umgeleitet.

Fork Clonen

Zur weiteren Bearbeitung clonen wir nun den Fork in ein lokales Repository auf unserem PC:

$ cd 
$ git clone Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.:/site-ffggrz.git
$ cd site-ffggrz

Bearbeitung

Aktualisierung

Falls nicht schon geschehen, wechseln wir un unser lokales Repository und bringen dieses auf den aktuellen Stand:

$ cd /site-ffggrz
$ git pull

Auschecken des gewünschten Branches

Als Beispiel wollen wir eine neue Beta-Version der Firmware erstellen. Dazu nutzen wir den Branch mit der Konfiguration für die aktuell stabile Gluon-Version:

$ git checkout

Änderungen durchführen

Nun können wir mit einem Editor unserer Wahl die Änderungen durchführen, welche zu einer neuen Version führen sollen. Danach sollte mit dieser Konfiguration die Firmware neu gebaut und getestet werden. Erst nachdem das erfolgreich war, machen wir mit Git weiter.

Wichtig: Es sollte generell immer nur eine Funktionalität geändert und getestet werden, um diese danach wie im folgenden beschrieben zu committen. Somit kann für jede Änderung ein separater Pull-Request erstellt werden, welcher bei Bedarf z.B. auch wieder zurückgenommen werden kann.

Änderungen Committen

Die Änderung wird nun, mit einer kurzen Beschreibung versehen, ins lokale Repository aufgenommen,  committet und anschließend ins persönliche Repository auf Github gepusht:

$ git add *
$ git commit -m ""
$ git push origin

Übertragen ins offizielle Repository

Pull-Request

Nachdem das persönliche Repository den gewünschten Stand erreicht hat, müssen die Änderungen ins offizielle Repository unserer Community übertragen werden. Das geschieht über die Weboberfläche von Github.

Dazu wird im persönlichen Repository auf den Schalter zum Erstellen eines Pull-Requests geklickt:

Danach kann man Repositories und den Branch als Quelle und Ziel auswählen:

Links sind Ziel-Repository und -Branch angegeben, rechts Quell-Repository und -Branch. Darunter sind die durchgeführten Änderungen an den einzelnen Dateien ersichtlich, Durch Klick auf den "Merge"-Schalter wird der Pull-Request im offiziellen Repository (ffggrz) erstellt. Dort kann einer der Administratoren mit den erforderlichen rechten den Pull-Request mergen.

Details
Kategorie: Git

Unterkategorien

Allgemein

Freifunkkommune Gera

FAQ

Öffentlichkeitsarbeit

Flohmarkt

Soziale Projekte

Organisation

Anleitungen

Dokumentation

Seite 2 von 44

<name>space
geschlossen seit 28.09.2023 16:10 Uhr

Weitere Informationen

RSS

Veranstaltungen / Ereignisse

Mi Okt. 04 @18:00 - 22:00
namespace geöffnet