Zufällige 'betrifft' Ordner und '.keep'-Dateien

87

Ich lerne Schienen.

Irgendwann bemerkte ich, dass scheinbar zufällige Ordner und Dateien im Verzeichnis meiner Rails-App angezeigt werden. In einigen Ordnern befindet sich ein concernsOrdner mit einer .keepDatei darin. Die .keepDatei scheint leer zu sein. In anderen Ordnern gibt es keinen concernsOrdner, aber eine leere .keepDatei ist vorhanden.

Weiß jemand, was mit diesen Dateien / Ordnern zu tun hat?

git version-control

— Alex Vallejo
quelle

131

.keepDateien sind 0-Byte-Dateien, die verhindern sollen, dass leere Ordner von allen möglichen Prozessen ignoriert werden. Nichts, über das man sich sorgen sollte.

— DickieBoy
quelle

2

vielen Dank! Also soll ich sie verlassen? Ich wollte sie löschen, wenn sie nicht notwendig sind

— Alex Vallejo

4

Ja, Sie sollten sie behalten, damit sie da sind, wenn Sie sie brauchen. Außerdem wird sichergestellt, dass die Ordner von Ihrem Versionskontrollsystem wahrgenommen werden.

— Josh

Soll ich sie in meine stecken .gitignore? Ich möchte lieber keine leeren Dateien festschreiben.

— tbodt

6

@tbodt Ich würde sie begehen. Ich bin mir nicht sicher, was passieren würde, wenn jemand anderes Ihre Codebasis klonen würde.

— DickieBoy

33

.keep-Dateien sind besonders hilfreich, wenn Sie leere Verzeichnisse mit git festschreiben möchten.

Lustige Tatsache, der Name .keepoder .gitkeepist bedeutungslos. Sie können die Datei .foofür denselben Effekt aufrufen , es handelt sich lediglich um eine lesbare Konvention.

Die .keepDateien dienen auch dazu, den Transport von einem VCS zum anderen zu erleichtern und das Löschen wichtiger Verzeichnisse zu verhindern, wenn Sie die Zusammenführung aufheben, wodurch diese Verzeichnisse leer werden.

Stellen Sie sich beispielsweise ein Skript vor, das versucht, cd dirin ein Verzeichnis zu gelangen, das von git nicht verfolgt wird.

Es ist ein Software-Design-Paradigma, das darauf abzielt, die Anzahl der Entscheidungen, die Entwickler treffen müssen, zu verringern, um Einfachheit zu erlangen, aber nicht unbedingt an Flexibilität zu verlieren.

— lfender6445
quelle

6

Bedenken sind ein einfaches, aber wirkungsvolles Konzept. Es ist für die Wiederverwendbarkeit von Code vorhanden. Grundsätzlich besteht die Idee darin, allgemeine und / oder kontextspezifische Codestücke zu extrahieren, um die Modelle zu bereinigen und zu vermeiden, dass sie zu fett und unhandlich werden.

Ich möchte ausdrücklich angeben, dass Sie Serviceobjekte verwenden sollten, um Funktionen bereitzustellen, die nicht das spezifische Objekt betreffen. ZB hat eine Organisation viele Benutzer. Jetzt muss der Administrator der Organisation eine CSV aller Benutzer für diese Organisation exportieren. Dieser Code kann in das Organisationsmodell eingefügt werden. Da er jedoch nicht in der Verantwortung des Organisationsobjekts liegt, sollte dieser Code in eine Klasse eingefügt werden, in der Sie nur das Organisationsobjekt übergeben und die CSV aller Benutzer zurückgeben.

 class Services::GenerateCsv
     def self.get_users org
         #add logic the fetch users for the org and generate the CSV and return the CSV data
     end
 end

Wann immer Sie eine CSV-Generierung benötigen, können Sie diese Logik in die obige Klasse einfügen. Dieser Ansatz hält das Objekt (in diesem Fall das Organisationsmodell) von dem Code frei, für den es nicht verantwortlich sein sollte. Ein allgemeines Prinzip, dem ich folge, lautet: Wenn der Code das Selbstobjekt ändert, verschieben Sie den Code in ein Serviceobjekt.

Hinweis: Ihre Frage betraf Bedenken, aber ich dachte darüber nach, einige zusätzliche Dinge hinzuzufügen, die ich befolge, um die Codebasis sauber und verwaltbar zu halten, da dies möglicherweise anderen Programmierern helfen könnte. Dieser obige Ansatz ist umstritten.

— prasad.surase
quelle