git 随机“关注”文件夹和“.keep”文件
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17928581/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Random 'concerns' folders and '.keep' files
提问by Alex Vallejo
I am learning rails.
我正在学习导轨。
Somewhere along the line, I noticed that seemingly random folders and files are appearing in my rails app's directory. In some folders there is a concernsfolder with a .keepfile inside it. The .keepfile appears to be empty. In other folders there is no concernsfolder but an empty .keepfile is present.
沿着这条线的某个地方，我注意到看似随机的文件夹和文件出现在我的 rails 应用程序的目录中。在某些文件夹中有一个concerns文件夹，.keep里面有一个文件。该.keep文件似乎是空的。在其他文件夹中没有concerns文件夹，但存在一个空.keep文件。
Does anyone know what the deal with these files/folders is?
有谁知道这些文件/文件夹的处理方式是什么？
回答by DickieBoy
.keepfiles are 0 byte files that are there to stop empty folders from being ignored by all sorts of processes. Nothing to worry about.
.keepfiles 是 0 字节文件，用于阻止空文件夹被各种进程忽略。没什么可担心的。
回答by lfender6445
.keep files are especially helpful when you want to commit empty directories with git.
当你想用 git 提交空目录时，.keep 文件特别有用。
Fun fact, the name .keepor .gitkeepis meaningless. you can call the file .foofor the same effect, its merely a readable convention.
好玩其实，名字.keep还是.gitkeep没有意义的。您可以调用该文件.foo以获得相同的效果，它只是一个可读的约定。
The .keepfiles are also there to aid portage from one vcs to another, preventing the deletion of important directories when you un-merge something that would cause those directories to be empty.
这些.keep文件还可以帮助从一个 vcs 移植到另一个 vcs，防止在您取消合并会导致这些目录为空的内容时删除重要目录。
For example, consider a script which attempts to cd dirinto a directory that is untracked by git.
例如，考虑一个尝试cd dir进入 git 未跟踪的目录的脚本。
It's a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.
它是一种软件设计范式，旨在减少开发人员需要做出的决策数量，获得简单性，但不一定会失去灵活性。
回答by prasad.surase
Concerns is a simple but powerful concept. It exists for code reusability. Basically, the idea is to extract common and / or context specific chunks of code in order to clean up the models and avoid them getting too fat and unmanageable.
关注是一个简单但强大的概念。它的存在是为了代码的可重用性。基本上，这个想法是提取常见的和/或上下文特定的代码块，以清理模型并避免它们变得过于庞大和难以管理。
I would like to specify explicitly that you should use service objects to provide functionality that's not the concern of the specific object. Eg a organisation has many users. Now the admin of organisation needs to export a CSV of all users for this organisation. This code can be placed in organisation model but since its not the responsibility of the organisation object, this code should be placed in a class where u just pass the organisation object and it returns the CSV of all users.
我想明确指定您应该使用服务对象来提供特定对象不关心的功能。例如，一个组织有很多用户。现在组织的管理员需要导出该组织所有用户的 CSV 文件。这段代码可以放在组织模型中，但由于它不是组织对象的责任，所以这段代码应该放在一个类中，您只需在其中传递组织对象并返回所有用户的 CSV。
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
Whenever you need CSV generation, u can place to that logic in the above class. This approach keeps the object (in this case, the organisation model) clean from the code that shouldn't be its responsibility. A general principle that I follow is: if the code it's modifying the self object, move the code to a service object.
每当您需要生成 CSV 时，您都可以在上面的类中放置该逻辑。这种方法使对象（在本例中为组织模型）远离不应由其负责的代码。我遵循的一般原则是：如果代码正在修改 self 对象，则将代码移动到服务对象。
Note: Your question was regarding concerns but I thought of adding some extra stuff that I follow to keep the code base clean and manageable since it might help fellow programmers. That above approach is debatable.
注意：您的问题是关于问题，但我想添加一些我遵循的额外内容，以保持代码库的清洁和可管理性，因为它可能对其他程序员有所帮助。上述方法值得商榷。
