适用于组合操作系统和私有代码的Git工作流程？ [英] Proper Git workflow for combined OS and Private code?

问题描述

我有一个封闭的源代码项目，它建立在我的开源框架之上。我想知道我应该如何构建我的工作流程。下面是使用git和子模块的最佳猜想。

1. 我在
   github上创建了一个公共框架回购，子模块为
   单独的git回购。


2. 我在github上购买
   micro帐户（$ 7），所以我
   可以有私人回购。


3. 我创建一个私有仓库并克隆公共框架仓库。

进行更改：

1. 我的私人代码和推送到我的私人回购github上


2. 公众框架代码并推送到我的私人github回购，然后从公共框架发送拉请求..？或者如何工作？

如何处理包含私有和公共代码和子模块的repo。现在看来，我只需要维护两个独立的代码库就可以实现这一目标。

我正在寻找可以帮助相当新的git简化在半开放源代码和半私有代码库上工作的过程。关于它的一个好处是，每个文件夹都是私人或公共的，所以不必担心私人和公共文件会聚集在一起 - 但一些私人文件夹可能是公开的！

我可以给出的另一个例子是使用zendframework来构建您的私人公司网站，同时仍然可以每天（并且可能会将补丁推到）zend repo。

例如，假设一个像这样的目录结构：

  / private_folder 
 / public 
 / public_folder 
 / public_folder2 
 / private_folder 
  

也许我要求两个人在一个加入的repo目录中处理它们。也许有没有简单的方法来做到这一点，我应该分开他们，并在一个公共补丁，然后拉入我的私人回购。当然，这意味着如果我正在处理一些私人代码 - 我不得不离开这个回购站并打开公共代码并修改代码，然后返回私人代码，合并，然后继续使用私有代码。

解决方案

我建议不要使用git子模块，但不要使用2个不同的存储库连接在github上。

您可以在签出的副本上使用符号链接来建立它们之间的关系，这是基本和简单的。符号链接只需要在每个位置创建一次（生产，开发，同事）。

优点是没有人需要额外的努力来学习和维护git子模块，避免了它带来的风险和复杂性。

可以通过在本地计算机上的某处保留os和git repo的工作副本来完成：

  / repos / myproject-os 
 / repos / myproject-priv 
  

然后你可以创建你的目录结构，其中的项目实际上将会在这台机器上的其他地方生存和工作（不在/ repos / tree ）并为您使用的子目录创建符号链接：

  ln -s / repos / myproject-os / dir1 / wrk / myproject / base / dir1 
 ln -s / repos / myproject-os / dir2 / wrk / myproject / base / dir2 
 ln -s / repos / myproject-priv / dir1 / wrk / myproject / base / dir3 
 ln -s / repos / myproject-priv / dir2 / wrk / myproject / base / someother / dir4 
 mkdir / wrk / myproject / base / config 
 mkdir / wrk / myproject / base / tmp 
  

通过这种方式，您可以始终保持存储库结构的清洁，并且可以按照您希望的方式从两个存储库中混合和排列目录，并且还可以为本地配置或临时文件创建空间，这些空间不会进入存储库。

您将执行git提交以及/ repos / tree中的所有内容，并且您的项目将运行，并且您将编辑/ wrk / tree中的文件。请注意，git数据所在的.git diretory将不能从/ wrk / tree中获得，因为您只链接到子目录（或者可能来自根目录的单个文件）。

Part2：你说你要确保你不会意外地将私人代码推入公共存储库。你可以在你的工作OS版本库和github版本库之间建立一个额外的git仓库，假设你把它放到/ repos / gatekeeper中，那么你的树就像这样：

  / repos / gatekeeper / myproject-os 
 / repos / myproject-os 
 / repos / myproject-priv 
  

每当你从/ 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 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.

1. I create a public framework repo on github with submodules that are separate git repos.
2. I purchase a "micro" account on github ($7) so I can have a private repo.
3. I create a private repo and clone the public framework repo.

From here I can make changes to:

1. My private code and push to my private repo on github
2. 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.

解决方案

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:

/repos/myproject-os
/repos/myproject-priv

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:

ln -s /repos/myproject-os/dir1 /wrk/myproject/base/dir1
ln -s /repos/myproject-os/dir2 /wrk/myproject/base/dir2
ln -s /repos/myproject-priv/dir1 /wrk/myproject/base/dir3
ln -s /repos/myproject-priv/dir2 /wrk/myproject/base/someother/dir4
mkdir /wrk/myproject/base/config
mkdir /wrk/myproject/base/tmp

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:

/repos/gatekeeper/myproject-os
/repos/myproject-os
/repos/myproject-priv

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工作流程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！