文件夹vs仓库在github [英] folder vs repository in github
问题描述
我是 github.com 的新用户，我正尝试创建一个包含两个部分的移动应用程序：客户端代码和服务器代码。客户端代码将使用Android for Java，Swift for iOS和C＃for Windows Phone编写。服务器端将用PHP，HTML，Javascript和CSS编写。
我的问题是：我应该如何构造代码？我应该将服务器代码和客户端代码放在不同的存储库中，还是应该将它们放在同一个存储库中的不同文件夹中？另外，因为有多个客户端（Android，iOS和Windows），我应该将它们放在不同的存储库或不同的文件夹中吗？
我已经知道任何一个都可以完成，但我想知道标准程序是什么，以及它的优点/缺点。
这个问题有很多可能的解决方案。由saljuama提供的答案是最完整的。
在github上查看了一些项目后，我发现一种方法是为客户端和服务器创建单独的存储库。如果你有多个客户端代码（就像我的情况一样），你可以使用同一个存储库，但使用不同的makefile。 b
$ b
我发现了这种方式 https://github.com/CasparCG server 与客户端不同。此外，客户端共享相同的src，lib和其他文件夹，但构建脚本<每一个的不同。正如Saljuama指出的，当你的客户共享相同的代码库时，这种方法是有意义的。如果您的客户不共享相同的代码库，请参阅saljuama的答案。
这不是唯一可行的方法。你可以用你自己的方式来完成。
解决方案这个话题非常广泛，但我会尽量保持中立。
根据12factor的第一原则代码库，每个应用程序应该有自己的代码库（或存储库）。由于客户端和服务器是不同的应用程序，因此它们不应该共享相同的repo。
使用同一个存储库的原因之一是一个坏主意持续集成和连续交付系统。由于存储库推送通常会触发这些流程，因此在其中一方执行更改时，CI / CD服务器将在应用程序的两端进行处理，而不需要它。
我能想到的其他原因可能会被归类为基于意见，所以我不会说明它们。
更新：
要回答您问题的更新，相同的代码库，如果您继续阅读有关12因子应用原则的信息，请配置和 builds ，那么一个回购就是你应该使用的。
I am a new user to github.com and I am trying to create a mobile app that has two parts: client code and server code. The client code will be written in Java for Android, Swift for iOS and C# for Windows Phone. The server side will be written in PHP, HTML, Javascript and CSS.
My question is this: how should I structure the code? Should I put the server code and the client code in different repositories or should I just put them in different folders in the same repository? Also, since there are multiple clients (Android, iOS and Windows) should I put them in different repositories or different folders?
I already know that either one can be done, but I want to know what the standard procedure is and what the advantages/disadvantages are.
There are many possible solutions to this issue. The answer provided by saljuama is the most complete.
After looking at a few projects on github I found that one way to do this is to create separate repositories for the client and the server. If you have multiple client codes (as in my case) you can use the same repository but different makefiles.
I found this way of doing things at https://github.com/CasparCG The server is a different repository than the client. Additionally, the clients share the same src, lib and other folders but the build scripts of each is different. As noted by saljuama this method makes sense when your clients are sharing the same codebase. If your clients do not share the same codebase see saljuama's answer.
This is not the only possible way. You can do it in your own way.
The topic is quite broad and it might be opinion based, but I'll try to stay as neutral as possible.
According to the 12factor first principle codebase, each application should have its own codebase (or repository). Since client and server are different applications, they shouldn't share the same repo.
One reason of why having both in the same repository is a bad idea, is when using Continous Integration and Continous Delivery systems. Since a repository push is what usually triggers these processes, performing a change on one of the sides would make the CI/CD server to process both sides of the application, when there is no need for it.
The rest of the reasons I can think of, are subject to be categorized as opinion based, so I won't state them.
Update:
To answer to the update on your question, if the different clients have the exact same codebase, if you keep reading about the 12-factor app principles, configuration and builds, then one repo is what you should use.
这篇关于文件夹vs仓库在github的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
