组合操作系统和私有代码的正确 Git 工作流程？
我有一个基于我的开源框架构建的闭源项目。我想知道我应该如何构建我的工作流程。下面是我使用 git 和子模块的最佳猜测。
- 我创建了一个公共框架存储库 github 的子模块是 单独的 git 存储库。
- 我购买了一个 github 上的“微型”帐户（7 美元）所以我 可以有一个私人仓库。
- 我创建一个私有存储库并克隆公共框架存储库。
从这里我可以更改：
- 我的私有代码并推送到 github 上的私有存储库
- 公共框架代码并推送到我的私有 github 存储库，然后从公共框架发送拉取请求..？或者这将如何运作？
如何处理包含私有和公共代码以及子模块的存储库。现在看来我只需要维护两个单独的代码库即可实现此目的。
我正在寻找最好的答案，可以帮助 git 新手简化半开源半私有代码库的工作流程。它的一个好处是每个文件夹要么是私有的，要么是公共的，因此不必担心将私有和公共文件放在一起 - 但某些私有文件夹可能位于公共文件夹中！
我可以举的另一个例子是使用 zendframework 构建您的私人公司站点，同时仍然能够每天向 zend 存储库进行拉取（也许还可以推送补丁）。还可以在 zendframework 内拉动和推送您的私人站点。
例如，想象一下这样的目录结构：
/private_folder
/public
/public_folder
/public_folder2
/private_folder
也许我要求两个人在一个连接的存储库目录中处理所有这些内容。也许没有简单的方法可以做到这一点，我应该将它们分开并在一个中完成所有公共补丁，然后将其拉入我的私人存储库。当然，这意味着如果我正在处理一些私有代码 - 我将不得不离开该存储库并打开公共存储库并更改修补后的代码，然后返回到私有存储库，合并，然后继续处理私有代码。
I have a closed source project that is built on my open source framework. I want to know how I should structure my workflow. Below is my best guess using git with submodules.
- I create a public framework repo on
github with submodules that are
separate git repos. - I purchase a
"micro" account on github ($7) so I
can have a private repo. - I create a private repo and clone the public framework repo.
From here I can make changes to:
- My private code and push to my private repo on github
- The public framework code and push to my private github repo and then send a pull request from the public framework..? Or how would this work?
How do I handle a repo that contains private and public code and submodules. Right now it seems like I just have to maintain two separate codebases to achieve this.
I'm looking for the best answer that can help someone fairly new to git streamline the process of working on a codebase that is half open source and half private. One good thing about it is that each folder is either private or public so there is no worry about having private and public files together somewhere - yet some of the private folders might be in public ones!
Another example I could give would be using zendframework to build your private company site while still being able to do pulls each day (and maybe patch pushes) to the zend repo. And also pulls and pushes of your private site inside the zendframework.
For example, imagine a directory structure like this:
/private_folder
/public
/public_folder
/public_folder2
/private_folder
Perhaps I'm asking two much to handle them all in one joined repo directory. Maybe there is no easy way to do this and I should separate them and do all the public patches in one and then just pull into my private repo. Of course, this means that if I am in the middle of working on some private code - I'll have to leave that repo and go open up the public one and make the patched code change, then go back to the private one, merge, and then continue working on the private code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我建议不要使用 git 子模块，而是使用 github 上未连接的 2 个不同的存储库。
您可以使用签出副本上的符号链接来构建它们之间的关系，这是基本且简单的。每个位置（生产、开发、同事）只需创建一次符号链接。
优点是没有人需要付出额外的努力来学习和维护 git 子模块，并且您可以避免它带来的风险和复杂性。
这可以通过在本地计算机上的某个地方保留操作系统和私有 git 存储库的工作副本来完成：
然后您可以创建目录结构，项目实际上将在该结构中生存并在该计算机上的其他地方（不在内部） /repos/ 树）并为您使用的子目录创建符号链接：
这样您的存储库结构始终是干净的，并且可以按照您想要的方式混合和排列两个存储库中的目录，并且您还有一个用于本地配置或的空间不进入存储库的临时文件。
您将执行 git 提交以及 /repos/ 树中的所有内容，并且您的项目将运行，并且您将编辑 /wrk/ 树中的文件。请注意，git 数据所在的 .git 目录无法从 /wrk/ 树中获得，因为您仅链接到子目录（或者可能是根目录中的单个文件）。
第二部分：您说您希望确保不会意外地将私有代码推送到公共存储库中。您可以在工作操作系统存储库和 github 存储库之间设置一个额外的 git 存储库，假设您将其放入 /repos/gatekeeper，那么您的树如下所示：
每次从 /repos/myproject-os 推送时，它都会转到/repos/gatekeeper/myproject-os.
但是从 /repos/myproject-priv 您可以直接推送到您的私人 github 存储库。
这样，您就可以在 /repos/myproject-os 和 /repos/myproject-priv 中拥有相同的工作流程，并且无需担心太多。有时，当您想要将更改推送到真正的操作系统代码库时，您可以访问 /repos/gatekeeper/myproject-os 并从那里推送到 github。
您可以在此之前进行额外的代码审查并查看差异，这样您就可以确定只有您真正想要的内容才会公开。
如果您想要额外的安全性，/repos/gatekeeper/myproject-os 也可以位于不同的计算机甚至不同的位置。
I recommend not to use git submodules, but 2 different repositories that are not connected on github.
You could build the relationship between them using symlinks on the checked out copies, which is basic and simple. The symlinks only have to be created once per location (production, development, coworkers).
The advantage is that nobody has to do the extra effort to learn and maintain git submodules, and you avoid the risk and complexity it brings.
It could be done by keeping a working copy of the os and of the private git repo somewhere on your local machine:
Then you could create create your directory structure where the project actually will live and be worked on somewhere else on this machine (not inside the /repos/ tree) and create symblinks for the subdirectories you use:
That way you have the repository structure always clean and can mix and arrange the directories from both repositories the way you want them, and you have also a space for local configs or temp files that do not go into the repositories.
You would do the git commits and everything from the /repos/ tree and your project would run and you would edit the files from the /wrk/ tree. Please note that the .git diretory where the git data lives would not be available form the /wrk/ tree, because you only link to subdirectories (or possibly single files from the root directory).
Part2: You say you want to make sure that you do not accidently push private code into the public repository. You could set up an additional git repository between your working OS repository and the github repository, let's say you put it into /repos/gatekeeper, then your tree looks like this:
Every time you push from /repos/myproject-os it goes to /repos/gatekeeper/myproject-os.
But from /repos/myproject-priv you push directly to your private github repo.
That way you have the same workflow in both /repos/myproject-os and /repos/myproject-priv and you don't need to worry so much. From time to time when you want to push your changes to the real OS codebase, you go to /repos/gatekeeper/myproject-os and push from there to github.
You could do additional code review before that and look at the diffs so you are sure that only that what you really want goes public.
If you want additional security the /repos/gatekeeper/myproject-os could also be on a different machine or even different location.
您可以在本地存储库中拥有“公共”和“私有”分支。当您推送时，每个分支都会被推送到一个单独的远程存储库（查找“git Push”语法）。然后，您可以自由地从公共合并到私有。
我确信有一种方法可以将选定的更改从私人合并到公共，尽管我必须查找它。
You can have a 'public' and 'private' branch in your local repository. When you push, each branch gets pushed to a separate remote repository (look up the 'git push' syntax). Then, you can freely merge from public to private.
I'm sure there's a way you could merge selected changes from private to public, too, though I'd have to look it up.
git submodules允许您定义配置（请参阅这个问题），这是对另一个组件（在另一个存储库中）的一次提交的引用。您可以在同一个存储库中开发两个代码（您的代码和子模块），但是当您在公共代码中讨论多个私有目录时，需要 子树合并策略。
它将允许您将您的目录（私有和公共目录）视为一棵自然的工作树。
为了更好地管理全局存储库的部分内容到私有存储库的推拉操作，我建议使用 git 子树脚本工具。
git submodulesallows you to define a configuration (see this question), that is a reference to one commit of another component (in another repo).You can develop both codes (your and the submodules) within the same repo, but when you are talking about multiple private directories within your public code, that calls for a subtree merge strategy.
It will allow you to consider your directories (the private and public ones) as one natural working tree.
And to better manage the push and pull of parts of your global repo to a private one, I would recommend the git subtree script tool.
总而言之，我推荐这个工作流程：
我过去使用过 git 子模块。我认为它们不太适合您的用例。我突然意识到的一个大缺点是：
我承认这是一个不太明确的子问题：“哪种工作流程可以更轻松地在 OSS 框架和私有项目之间来回切换？”
使用子模块并将两个项目放在一棵树中具有一定的吸引力。这可能会加快您的文本编辑速度，但在提交和推送时可能会减慢您的速度（或导致比平常更多的错误）。
将项目分开具有一定的吸引力。上下文切换（从一个文本编辑器窗口到另一个文本编辑器窗口）可能有助于提醒您 OSS 项目是供公共使用的。例如，它可能有助于约束您不要破坏向后兼容性并保持良好的变更日志。相对于子模块替代方案，提交和推送会更容易。
一旦您决定了工作副本，您就会想要弄清楚您的日常工作流程。当然，这取决于您的语言。 （例如，在 Ruby 中，您可以将 OSS 框架打包为 gem，构建它，然后让您的私有代码依赖它。）无论您选择什么，设置一些脚本（或者编辑器快捷方式）来帮助您构建库（或包）快速，甚至在文件更改时自动进行，以便您可以轻松地在框架和项目之间切换。
To summarize, I recommend this workflow:
I've used git submodules in the past. I don't think they are a good fit for your use case. The big downsides that jump out at me are:
Here is one sub-question that I will admit is not so clear cut: "Which workflow makes it easier to bounce back and forth between the OSS framework and the private project?"
There is a certain allure to using submodules and having both projects in one tree. This will speed you up perhaps in your text editing, but probably will slow you down (or cause more mistakes than usual) when it comes to committing and pushing.
There is a certain allure to having the projects separated. The context switch (from one text editor window to another) may help remind you that the OSS project is for public consumption. For example, it may help discipline you to not to break backwards compatibility and to keep a good changelog. Committing and pushing will be easy relative to the submodule alternative.
One you have decided on your working copies, you'll want to figure out your day to day workflow. It will depend on your language of course. (In Ruby, for example, you might package up your OSS framework as a gem, build it, then have your private code depend on it.) Whatever you pick, setup some scripts (or editor shortcuts perhaps) to help you build your libraries (or packages) quickly, perhaps even automatically when files change, so that you can bounce between your framework and project effortlessly.
这里有两种方法：
您可以使用同一 git 存储库的分支。在您的私人存储库中创建一个分支，并引用您的公共存储库并像这样处理两者。
如果您的私有项目中使用的组件是公共项目的子项目，那么您应该使用子模块。子模块的处理在 git 1.6.6 版本中处于早期阶段，但作为您使用的子项目可能很有用。
在我看来，如果哪个项目对每个项目都有贡献，你就不能失去它，所以如果你清楚这一点，那么无论你选择什么，它都会起作用！
此外，
git很简单。There's two approach here:
You could use branch's of the same git repo. In your private repo create a branch with a reference to your public repo and handle both like that.
If the components using in your private project are sub-project of your public stuff, then you should use submodules. The handling of submodule is in a kind-of early stage on git at version 1.6.6, but could be useful as your using subproject.
What is seems to me you can't loose if which project tribute to each project, so if you have that clear, then no matter what you choose it'll work !!!!!!.
Besides
gitis easy.将公共存储库作为私有存储库中的子模块。推动时，请记住您必须同时推动它们。还要记住在私有存储库中签入子模块本身，以便它跟踪它正在使用的子模块的修订版本。
Make the public repo a submodule inside the private one. When pushing, remember you have to push them both. Also remember to check in the submodule itself in the private repo, so it tracks what revisions of the submodule it is using.