git

Gängige Praxis, nicht nur bei uns: Test-Systeme, auf denen die Kundin neue Features testen kann, ohne dass gleich das Live-System aktualisiert wird. Das soll dann aber nicht für die ganze Welte erreichbar sein... wir verwenden apache als Webserver, dort ist die wohl häufigste Lösung der sogenannte htaccess-Schutz, im einfachsten Fall etwas so:

AuthType Basic
AuthName "Unser Test-System"
AuthUserFile /path/outside/of/webroot/.htpasswd
Require valid-user

Das von mir gerne eingesetzte Modul security_review hat grade auf einer unserer Sites festgestellt, dass in der .htaccess im files-Ordner noch

<IfModule mod_php5.c>
   php_flag engine off
</IfModule>

anstatt korrekt

<IfModule mod_php7.c>
   php_flag engine off
</IfModule>

also mod_php7 stand.

Ich arbeite viel mit "Dev-Modulen" wie environment_indicator, reroute_email oder stage_file_proxy.
Problem ist dabei ja, dass das nicht in die git-verwaltete config kommen soll(te).
Genau dafür gibt es das setting 'config_exclude_modules'.

Schon wieder eine Gratulation: good old Linux ist tatsächlich nicht nur good sondern auch quite old inzwischen: nämlich 30 Jahre!

Wir können kaum in Worte fassen, wir stark wir auf Linux zurückgreifen...
Für fast alle unsere Webprojekte nutzen wir Linux als Server als Entwicklungs- und Produktions-System (davon überwiegend debian GNU/Linux).

Weil ich es immer wieder suche: Wie kriege ich den Namen des git-Repositories raus?

Ziemlich einfach: git remote show origin

Voraussetzung ist, dass das die Information überhaupt vorhanden ist - was normalerweise, d.h. beim Anlegen des ganzen per clone auch der Fall ist.

Wenn das Repo allerdings per git init erzeugt wurde oder der Link zum original remote gelöscht wurde (git remote rm origin), dann gibt es die Information einfach nicht...

Bei Drupal 8 Projekten wir die Datei composer.lock immer zum Git Repository hinzugefügt. Wenn mehre Entwicklerinnen gleichzeitig Module installieren oder updaten kann es zu Merge Konflikten in dieser Datei kommen. Durch die Struktur dieser Datei ist es nicht sinnvoll diese von Hand zu mergen.

Eine Möglichkeit das Problem zu beheben ist der Aufruf:

Ab und zu passiert es: Datei falsch ins git commited, falschen Kommentar geschrieben, o.ä.
Nicht so oft, aber damit eben auch nicht oft genug, dass ich es mir merke.
Daher hier nochmal (auch wenn die SMDV es schnell findet): git commit ändern und zurücknehmen

Solange es nicht ge-push't ist, ist alles ganz einfach.