我的 OSS 项目的私有和公共 git 存储库

发布于 2024-11-09 04:04:33 字数 854 浏览 2 评论 0原文

stackoverflow 中有类似的问题,但没有一个正是我要问的,至少我找不到。

我正在启动一个 OSS 项目,我想在 github 上公开分享它。但我也想在我的服务器上有一个私有远程存储库。公共存储库用于项目的公共版本,私有存储库用于内部版本,尚未准备好发布。显然,公共存储库将始终是私有存储库的旧版本,并且私有存储库的内容在准备好之前不会被推送到公共存储库。

我在网上搜索,发现一些人提出的工作流程与我想要的非常相似。这是博客文章的链接,他们在其中解释了所有内容:http://www.braintree payments。 com/devblog/our-git-workflow

我喜欢它的一切,除了进入 github 上公共存储库的完全压缩的提交。我也有点不喜欢这样的部分:在合并到公共分支后,他们必须将所有内容重新合并回主分支和发布分支,尽管正如他们积极断言的那样,没有任何真正的改变可以在那里进行。

我的问题是,拥有一个公共回购历史记录只是一系列被压缩的提交,并且丢失了其中逻辑更改的所有细节,这真的很糟糕吗?这对我来说似乎很不自然,而且我也没有经常看到这种情况,但也许它并没有那么糟糕,或者我可以在没有 --squash 参数的情况下采用这个工作流程。

另外,从 github_master 重新合并回 master 和release分支的阶段又如何呢?我猜他们需要它是因为提交被压缩了。如果我决定不挤压,那么我认为这是没有必要的,但我不确定。

或者,有人可以建议一种不同的方法来做到这一点吗?考虑到如果有人 fork 我的 github 存储库,我也可能想要接受其他人的贡献。

there are similar questions here in stackoverflow, but none is exactly what I'm going to ask, at least none I could find.

I'm starting an OSS project, and I want to share it publicly on github. But I also want to have a private remote repo in a server of mine. The public repo is for the public version of the project, and the private repo is for an internal version, not ready for release. Obviously the public repo will always be a possibly old version of what's in the private, and stuff in the private will not be pushed to public until they're ready.

I searched over the net and I found some guys who came up with a workflow very similar to what I want. This is the link to the blog post where they explain everything: http://www.braintreepayments.com/devblog/our-git-workflow

I like everything about it, except for the totally squashed commits that go into the public repo on github. I also dislike a bit the part where, after merging into public, they have to re-merge everything back into master and release branches, even though, as they positively assert, there are no real changes to make there.

My question is, is it really bad to have a public repo history that's just a series of squashed commits that has lost all the details of the logical changes within it? It seems unnatural to me and I have not seen this a lot, but maybe it's not that bad, or else I can adopt this workflow without the --squash parameter.

Also, what about the phase of re-merging back from github_master to the master and release branches? I guess they need it because of the squashed commits. If I decide to not squash, then I think this is not needed, but I'm not sure.

Or else, can anyone suggest a different way to do this? Take into account that I would also possibly want to accept contributions from other people if someone forks my github repo.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

柒七 2024-11-16 04:04:33

如果您只是不希望未发布的更改在发布之前可见,并且不介意中间提交在发布后变得可见,那么这相当简单。您可以将您的私人分支机构视为......好吧,普通分支机构。只需确保私有分支名称不存在于 github 上(但存在于私有存储库中),并且默认推送设置应该能够处理这些事情。

不过,如果您确实想隐藏历史记录,那么,这就是基于挤压的工作流程的全部内容。在这种情况下,如果您合并外部分支,最好避免压缩它们的提交。

If you simply don't want the unreleased changes visible until they're released, and don't mind the intermediate commits becoming visible once they are released, then this is fairly simple. You can just treat your private branch as ... well, an ordinary branch. Just make sure the private branch name doesn't exist on github (but does exist in the private repo), and the default push settings should take care of things.

If you do want to hide history, though, well, that's what that squash-based workflow is all about. In this case, if you do merge external branches, it would be best to avoid squashing their commits.

爺獨霸怡葒院 2024-11-16 04:04:33

与其走这条路,为什么不将所有更改推送到 Github,而是在“master”以外的分支中 - 这样,人们默认会看到“安全”分支,但你不会失去历史。

如果您确实想对您的 dev 分支保密,您可以执行我所描述的操作,但不要推送 dev 分支 - dev 分支仅位于您的计算机本地。

Instead of going down this route, why don't you just push all of your changes to Github, but in a branch other than 'master' - this way, people will see the "safe" branch by default, but you won't lose the history.

If you really want to keep your dev branch a secret, you could do what I'm describing, but don't push the dev branch - the dev branch would be local to your machine only.

唔猫 2024-11-16 04:04:33

你的思路很好。如果您不愿意,则无​​需压缩提交。根据您的私人分支,您仍然希望将其推送到某个地方,以便您有备份。您可以将其推送到 U 盘上的裸克隆或像 unfuddle.com 这样拥有免费私人 git 存储库空间的地方。然后,您将设置 2 个遥控器:一个连接到 Github,另一个连接到 USB 记忆棒或 unfuddle。

另外,请记住,像第 3 方 DLL 这样的较大文件可能会增大您的存储库的大小,从而可能会阻止您免费进行解压。在这种情况下,使用子模块将这些文件保存在公共 github 存储库中,并且仅将您的实际源代码存储在您将推动解开的更高级别存储库中。

希望这有帮助。

You are fine in your line of thinking. You don't need to squash commits if you don't want to. As per your private branch, you still want to have that pushed somewhere so you have a backup. You can push it to a bare clone on a USB stick or a place like unfuddle.com where you have free private git repo space. You would then have 2 remotes set up: one to Github and another to either a usb stick or unfuddle.

Also, keep in mind that larger files like 3rd party DLLs may blow up the size of your repo, potentially inhibiting you from pushing to unfuddle for free. In this case, use submodules to keep those files in a public github repo and only store your actual source at the higher level repo which you would push to unfuddle.

Hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文