Tag: git

Zuerst benennen wir unser Master in Main lokal um:

git branch -m master main  

2. Nun möchten wir auf unserem entferntem Repository das selbe tun.

Ändert den master auf main in eurem entfernetem Repository (GitLab, GitHub etc.). Dann könnt ihr von lokal aus:

git push -u origin main

den neuen branch bespielen. Um den master jetzt zu löschen folgendes eingeben:

git push origin --delete master

Ich persönlich fand es unnötig und zu politisiert. In der Sache zwar richtig aber im grunde nicht zu ende gedacht. Grundsätzlich sind Menschen keine Heiligen und tun immer und ständig schlimme Dinge. Und das der eine Mensch den anderen Menschen beherrschen möchte gehört leider auch zum Menschsein dazu. Sklaverei hat auch viele Gesichter. Von Sklaverei auf der arabischen Halbinsel oder Nordost Afrika (Lybien) bis hin zur modernen Arbeitssklaverei in Indien, Pakistan. [Q: https://weltkirche.katholisch.de/Aktuelles/20190205_Moderne_Sklaverei_auf_der_Arabischen_Halbinsel] Selbst im privat, persönlichem Raum gibt es Abhängigkeiten die drauf aufbauen. Ich finde das war, ist und bleibt leider auch so. Egal ob man sein Hauptbranch jetzt main oder master nennt. Vielleicht ist es gerde nur en vogue.

Unsere System macht “Hintz und Kuntz” in der westlichen Welt, egal ob sie es einsehen oder nicht, zu Mastern. Jeder der ein Smartphone hat, jeder der ein Auto fährt, jeder der eine Fußball-Weltmeisterschaft in Katar sehen möchte, jeder der ständig neue Klamotten kauft ist ein Master. Denn er beutet indirekt woanders Menschen aus. Gegen Rassismus muss man andere Hebel in Gang setzen. Aber das würde eventuell den “Mainler” bzw. “Mastern” nicht gefallen und somit bleibt es so wie es ist.

Also Leute. Lange rede gar kein Sinn. Aber das ganze hat so was von “nichts” mit Git zu tun.

Allgemein kann man zwischen den einzelnen Git Branches springen. Aber wie sieht es aus, wenn man zwischen einzelnen Commits innerhalb einer Branch springen will? Ein Fall wäre, man arbeitet an einem Feature. Ist immer Feature Branche ausgecheckt und setzt während der Entwicklung kleinere Commits ab. Dann kommt die Stelle wo man sagt, ok ich muss doch so machen wie ich es vorher hatte. Aber man hat bereits mehrer Commits abgesetzt und kann auch nicht mehr mit der IDE zurück springen. Man braucht diese eine Funktion von damals. Wie kommt man da ran?

`git log –oneline –all`

`git checkout 20963d0`

und ihr seid in dem commit von damals. Holt euch euren code den ihr braucht und springt mit git checkout commit id die auf euren master verweist zurück.

Ihr habt ein lokales Repository und ein Remote Repository. Das Remote Repository liegt zum Beispiel bei GitHub und ihr wollt es nun aber bei GitLab unterbringen. Wie löscht man jetzt die Remote Config im lokalen Git Projekt Verzeichnis. Falls ihr noch nicht in dem gewünschten Verzeichnis seid, dann aber schnell hin da.

Mit git status checkt ihr noch mal ob ihr im richtigen Ordner seid.
Mit git remote -v werden dir alle Fernbeziehungen unserer lokalen Repositories angezeigt.

origin git@github.com:SeoTheater/xxx-yyy.git (fetch)
origin git@github.com:SeoTheater/xxx-yyy.git (push)

Und nun könnt ihr mit

git remote rm origin

die Remotebeziehung zu eurem GiHub oder Ähnlichem beenden. Den: “Nichts ist für die Ewigkeit.”

Viel Spaß beim UnRemoten!

Lange Zeit war mir das auch nicht klar, dass es Regeln für Git Commit Messages gibt. Wie sinnvoll die Regeln sind erschließt sich spätestens dann wenn man in größeren Teams arbeitet. Diese 7 Regeln möchte ich euch hier kurz erklären. Die Regel hat der Softwareentwickler Chris Beams vor einiger Zeit erstellt und auf seinem Blog veröffentlicht. https://chris.beams.io/posts/git-commit/

• Ausgehend davon, dass gut geschriebene Commit Nachrichten der beste Weg ist, um Kollegen (aber auch sich selbst) den Kontext einer Änderung mitzuteilen. Der Code bzw. ein git diff wird dir zeigen, was sich genau geändert hat, aber eine Commit Nachricht wird dir sagen warum sich das geändert hat.
• Trennen Sie den Betreff vom Text mit einer Leerzeile
• Begrenzen Sie die Betreffzeile auf 50 Zeichen
• Starten Sie Betreffzeilen immer mit einem Großbuchstaben
• Beenden Sie die Betreffzeile nie mit einem Punkt
• Verwenden Sie den Imperativ in der Betreffzeile und nicht die Vergangenheitsform
• Umfassen Sie den Textkörper mit 72 Zeichen
• Erklären Sie im Textkörper das Was und Warum, nicht das Wie

<type>[optional scope]<description>

feat(IAD-123): Add type for something.

<type>
Die zwei gängigsten Typen wären fix und feat. Aber es gibt noch weitere:

• fix (Nutzt du beim Bugfixing) |
• feat(nutzt du bei code features)
• build
• docks
• style
• refactor
• test
• chore
• ci

[optional scope]
Sind zusätzliche Infos wie zum Beispiel eine Ticketnummern oder ähnliches.

<description>
Hier schreibst Du eine kurze Nachricht rein. Nachrichten können sich zusammensetzen aus Betreff, Body, Fußnot. In den meisten Fällen genügt eine Betreffzeile. Im Optionalen Body schreibst Du dann ausführlich deine Änderungen rein und vor allem warum du diese gemacht hast. In der Fußnote kannst Du Tickets mit Hashtags angeben um dem Leser mehr Backgroundinformationen zu liefern.

Eine kleine Eselsbrücke für den Anfang: Du fängst den Commitsatz imaginär an: Dieser Commit möchte update readme file with new thinks.

Es kommt vor, dass man ein Feature für ein Projekt entwickeln soll und man zuerst ausprobiert was so geht. Ihr arbeitet an einem Remote Repository und entwickelt lokal. Dann schnell mal ein composer update und die composer.lock ist geändert. Ihr wollt am liebsten den ganzen Branch verwerfen und zum Step zurück wo ihr angefangen habt. Ohne Git wäre das jetzt STRESS-PANIK Deluxe. Mit Git super entspannt.

Es gibt natürlich wieder mal mehrere Lösungswege. Ich stelle hier zwei vor:

1. Der einfachste und schnellste Weg

In seid in dem Branch wo Ihr die Änderungen gemacht habt und ihr aber nicht haben wollt. Dann folgenden Git Command abfeuern:

git reset --hard HEAD 

2. Der Lange Weg – aber derhaut auch den ganzen Branche in die Tone

Ein andere Weg wäre nun den gesamten neuen Branch zu entfernen. Wenn ihr euch noch nicht im neuem Branch bewegt könnt ihr mit git checkout neuer_branch in den branch rein. Dann mit git add. && git commit-“Änderungen sind ins leere gelaufen, daher wird dieser branch gelöscht“.

Mit:

git branch -D neuer_branch 

löscht ihr den Branch.

Fazit:

Beide Wege sind legitim. Ich nutze aber meistens den ersten Weg (git reset –hard HEAD) weil ich zu 99% den Branch weiter nutzen will.

Der Artikel geht davon aus, dass ihr wisst was eine Versionsverwaltungssoftware ist. Ihr solltet auch die Git Grundbefehle wie init, add, commit kennen. Was immer wieder mal, auch bei Erfahrenden Codern, vorkommt ist das kleine .gitignore Chaos. Stellt Euch vor ihr habt bereits euer Initialcommit auf euer Repository gepusht. Dann stellt ihr fest: „Mist in meinem Projekt-Root Verzeichnis liegt ja meine devnotes.txt! Mit den ssh Zugängen und meinen Arztterminen, weil ich zu faul war das mir in mein Kalender zu hacken. Nicht schon wieder! f*c*!“ Wenn ihr wüsstet, was manche Entwickler so alles in ihrer Todolisten schreiben.

Nun haben wir augenscheinlich erst mal ein Problem. Aber das ist schnell gelöst.

Schritt 1: .gitignore Datei anlegen

Falls noch nicht geschehen, legt mit touch .gitignore im Projektroot die neue Datei an. Öffnet diese und schreibt die gewünschten Dateien oder auch Verzeichnisse rein, die zukünftig nichts mehr ins Repository gepusht werden sollen. In dem fiktiven Beispiel wäre es dann devnotes.txt.

#! das gehört in eure .gitignore Datei rein
# ignore theses files
devnotes.txt
# ignore theses folders
node_modules/

Dann erst mal:

git add . && git commit -m”added gitignore”
git push origin master

Wenn ihr im Team arbeitet müsst ihr vom Repro erst mal pullen. Allerdings muss dir hier dann bewusst sein, dass nun sehr wahrscheinlich dein Team deine Einkaufsliste kennt.

Schritt 2: Lösche die zu ignorierende Datei aus dem Repository

Jetzt haben wir eine gitignore die unsere devnotes.txt nicht mehr berücksichtigt. Aber das Problem ist hier noch nicht ganz gelöst. Ihr müsst nun die devnotes.txt aus dem Repository entfernen. Das machen wir mit:

git rm --cached devnotes
git commit -m”remove devnotes from repository ;-)”
git push origin master

Ein Fallstrick hier wäre die Commit Message. Diese verrät anderen nun, dass im Repository deine devnotes.txt liegen. Vielleicht sollte eure Commit-Message in diesem Fall etwas kryptischer ausfallen als sonst.

Ansonsten wäre wir nun hiermit durch und Problem gelöst.