Was ist der „Standard“-Verzeichnisspeicherort, der beim Klonen eines Git-Repositorys auf einen LINUX-Computer verwendet werden soll?
Lesezeit: 6 Minuten
Während ich die meiste Zeit meiner Karriere als Full-Stack-Webentwickler auf dem Microsoft-Stack verbringe, habe ich gelegentlich auch meinen Weg in die *NIX-Seite der Dinge gefunden. Ich habe hier einen FreeBSD-Webserver gebaut und einmal mit Caldera Linux gespielt dort drüben und führe derzeit eine Webbereitstellung mit einer Google Cloud-VM durch, auf der Ubuntu ausgeführt wird …
TL,DR
Wenn ich also ein Repo auf mein GitHub-Konto geforkt habe, alles zu dem Zweck, es dann auf meinen Ubuntu-Server zu klonen, wo ich dann die Webanwendung kompilieren und ausführen werde.
Was ist der professionell erwartete Ort, an dem ich diesen „geklonten“ Quellcode ablegen sollte? Ich habe ein bisschen gegoogelt, um besser zu verstehen, wozu die verschiedenen Linux-Verzeichnisse dienen. Aber… ich brauche eine gute SO-Antwort… also… wo würden Sie sie hinstellen?
/usr/src/MyGitRepos ..das hörte sich für mich gut an.. aber… was würdest du tun?
Was ich verwende, ist $HOME/repos/owner/repo-namewodurch die Dinge ziemlich organisiert bleiben.
– Benutzer663031
21. Januar 2016 um 4:08
Viraptor
Was ist der beruflich erwartete Standort?
Wenn Sie, wie Sie sagen, eine App bereitstellen, die aus dem Quellcode kompiliert wurde, gibt es keinen solchen Speicherort. In einer professionellen Umgebung landen Ihre Quellen nicht auf den Servern.
Von den professionellsten bis hin zu „es funktioniert“-Lösungen:
Erstellen Sie Systempakete außerhalb Ihrer Produktionsumgebung. Das bedeutet, dass Sie über ein Repository beider zuvor bereitgestellter Versionen und ein Paketmanifest verfügen, das sowohl Build- als auch Laufzeitabhängigkeiten enthält. Das bedeutet, dass Sie Ihre App jedes Mal auf die gleiche Weise neu erstellen können. Installieren Sie zur Installation das erstellte Paket. (Dies gilt für Deb, rpm usw.)
Erstellen Sie Tarballs mit Binärdateien in einer vorhersehbaren Umgebung (Entwicklerbox). Das bedeutet, dass Sie ausführen (z. B. wenn Sie Autotools verwenden) ./configure --prefix=/opt/your_app && make install DESTDIR=/tmp/somedirectory – Jetzt können Sie das packen /tmp/somedirectory/opt/your_app Inhalt, kopieren Sie ihn auf einen Server und entpacken Sie ihn dort /opt/your_app.
Klonen Sie es an einen beliebigen Ort (Ihr Home-Verzeichnis), erstellen Sie es und installieren Sie es dann am Ziel. Beliebte Reiseziele sind /opt/app_name Und /usr/local.
Die Lösung hängt davon ab, wie professionell die Bereitstellung wirklich ist, wie viele Server Sie haben, ob Sie über eine Test-/Produktionsumgebung verfügen usw.
ha ha.. jetzt wusste ich das aus der Entwicklung von ASP.NET.. nur der Ordner „bin“ wird veröffentlicht.. Ich hatte einfach nicht die richtige Einstellung.. Ich werde ganz „hackig“, wenn ich Linux mache Sachen und vergiss das Offensichtliche (oder, na ja… vielleicht… nicht so offensichtlich). Ich schätze die Auflistung der Schritte mit den Befehlszeilen-Codeschnipseln wirklich. Das ist die Antwort, nach der ich gesucht habe – sie bringt mich auf einen gesunden Weg.
– bkwdesign
21. Januar 2016 um 4:55
Wenn Sie es woanders hinstellen als $HOME Es liegt ein potenzielles Problem vor. wenn ein anderer Benutzer vorbeikommt und versucht, a auszuführen git Wenn Sie den Befehl für das Verzeichnis ausführen, geraten Sie in Schwierigkeiten (dieser Benutzer verfügt möglicherweise nicht über die Berechtigung, die Dateien im Verzeichnis zu ändern). .git Unterverzeichnis, auf dem sich beispielsweise Ihre Benutzer-ID befindet). Mein Vorschlag wäre, dass, wenn Sie eine gemeinsame Entwicklung beabsichtigen, jeder Benutzer seine eigene Kopie auf sich selbst klont $HOME ; Wenn Sie jedoch beabsichtigen, die Ergebnisse schreibgeschützt zu verwenden, klonen Sie sie irgendwo und rm -rf .git .
– MM
21. Januar 2016 um 8:22
Richtig, ich habe eine Rekursion durchgeführt chown Befehl kurz bevor ich den ausgeführt habe make ..was den Erfolg aller Paketverwaltungsaufgaben ermöglichte.. aber… ich verstehe, was Sie sagen.. Bei mir ist es gelungen
– bkwdesign
21. Januar 2016 um 17:10 Uhr
Ich würde nicht sagen, dass es einen standardmäßig angenommenen Ort gibt, insbesondere wenn der Server speziell für diese Anwendung gedacht ist. Es sollte auch in Ordnung sein, einen Ordner dafür im Verzeichnis /home/user abzulegen oder ihn von da an so zu organisieren, wie Sie es für richtig halten:
/home/user/app-goes-here/app.js
Halte es einfach einfach 🙂
ja, stecke es in die home/user/ Der Standort … macht Sinn … das ist im Grunde die Richtung, nach der ich gesucht habe – zusammen mit Ihrem Tipp, dass es keinen Standardort gibt. Ich brauchte nur eine unabhängige Bestätigung, dass mein Bauchgefühl in die richtige Richtung geht. Ich halte mich selbst nicht für *NIX-y genug, um meinen Instinkten zu vertrauen 😉
– bkwdesign
21. Januar 2016 um 4:05
Freut mich, dass ich Ihnen behilflich sein konnte 🙂 Solange es sich nicht um eine Bereitstellung auf großer Unternehmensebene handelt (und ich gehe davon aus, dass Sie diesbezüglich Anweisungen erhalten würden, wenn dies der Fall wäre), sehe ich keinen Grund, warum dies nicht geeignet wäre.
– Knoten
21. Januar 2016 um 7:32 Uhr
Wenn es von einem einzelnen Unix-Benutzer verwendet werden soll, irgendwo in $HOME ist für mich durchaus vernünftig. Wenn das Repo auch von anderen Benutzern verwendet werden soll, /opt ist beträchtlich.
Gut zu wissen – ja, das ist ein freiberuflicher Auftritt – ich baue im Grunde ein paar Server für einen Kunden zusammen, der dann alles übernimmt – mein Auftritt bei diesem Setup wird kurz sein
– bkwdesign
21. Januar 2016 um 4:07
Persönlich bin ich mit der Verwendung nicht einverstanden /opt (oder /local) zum Speichern von Git-Repos, da sie zum Speichern von Software gedacht sind. opt wird im Allgemeinen zur Lagerung verwendet Optional Software, die durch einfaches Entfernen des darin enthaltenen Ordners entfernt werden kann opt. Ähnlich, local ist für lokal installierte Software gedacht, die unabhängig von der Distribution selbst ist. /usr selbst speichert Binärdateien, die wiederum zum Hosten von Software gedacht sind. Außerdem ist ein Git-Repo nicht dazu gedacht, von Benutzern gemeinsam genutzt zu werden. Wenn eine Konteilung erforderlich ist, sollte das Repo von jedem Benutzer, der es verwendet, geklont werden. Für mich, home ist die bessere Wahl.
– alelom
10. März um 12:22
alelom
Ich würde sagen, dass home ist die beste Standortwahl zum Klonen eines Repos.
Persönlich bin ich mit der Verwendung nicht einverstanden /local oder /opt zum Speichern von Git-Repos, da sie zum Speichern von Software gedacht sind:
/opt ist grundsätzlich dafür gedacht Speicherung Optional Software Dies kann durch einfaches Entfernen des darin enthaltenen Ordners entfernt werden opt.
Außerdem glaube ich, dass ein Git-Repo nicht dazu gedacht ist, zwischen Benutzern geteilt zu werden. Wenn eine Aufteilung erforderlich ist, sollte das Repo von jedem Benutzer geklont werden, der es verwendet, anstatt dass verschiedene Benutzer denselben Ordner gemeinsam nutzen. Wenn die Festplattennutzung ein Problem darstellt, bedeutet dies wahrscheinlich, dass das Repo nicht ordnungsgemäß zum Speichern großer Dateien und nicht nur des Quellcodes verwendet wird, oder dass Sie möglicherweise auf Folgendes achten sollten: git-lfs für Hilfe.
14503600cookie-checkWas ist der „Standard“-Verzeichnisspeicherort, der beim Klonen eines Git-Repositorys auf einen LINUX-Computer verwendet werden soll?yes
Was ich verwende, ist
$HOME/repos/owner/repo-namewodurch die Dinge ziemlich organisiert bleiben.– Benutzer663031
21. Januar 2016 um 4:08