如何组织我的 Git 存储库

发布于 2024-11-24 07:05:23 字数 1482 浏览 0 评论 0原文

我面临以下问题,但没有答案:

我们有一个从 SVN 存储库克隆的存储库。存储在该存储库中的项目类似于可供各种项目使用的平台软件。存储库的结构是这样的:

platform
  |- core
  |- additional

由于某些原因,该存储库的结构无法更改。 核心附加都包含属于该平台的数据。

如果项目想要使用该平台并添加一些功能,它会在 additional 下创建一个包含源代码的新文件夹,并将该功能的标头添加到 additional/includes

目前,我们只需从 master 分支出新项目,所有内容都会进入同一个存储库。这导致分支膨胀,我的(中央)存储库变得越来越多,因为单个项目中所做的所有提交都会进入中央存储库(我的同事习惯了 SVN,所以他们 push几乎在每次提交之后——只是为了确定......)。

首先我想到的是 子模块:保留 < code>platform 作为超级项目下的子模块(称为 super),然后转到 super/platform/additional/mystuff,在那里创建源并添加它们到超级。但这显然不起作用,因为这些文件位于 platform 子模块内。

有没有更好的方法来组织我的存储库,以便:

  • 平台的用户能够从中央存储库更新他们的工作副本
  • 并且平台的用户能够将错误修复应用于platform
  • AND 使用 platform 的项目不会弄乱 platform 的存储库吗?

编辑1高度耦合的git子模块涵盖了相当多的内容我所处的场景:紧密耦合的东西,我是唯一一个比 git 的绝对基础知识多一点知识的人,“大多数开发人员对 git 的了解非常粗略”。完美搭配!


编辑2: 而迈克尔的答案 看起来很有希望,但我认为它使用起来有点太复杂了。我正在寻找一些非常简单的东西,不需要太多的交互。

I'm facing the following problem and don't have an answer to it:

We have a repo that was cloned from an SVN repo. The project stored in that repo is something like a platform software that gets used by various projects. The structure of the repo is like this:

platform
  |- core
  |- additional

The structure of that repo cannot be changed for some reasons. Both, core and additional contain data that are part of that platform.

If a project wants to use the platform and add some functionality, it creates a new folder under additional containing the sources and adds a header for that functionality to additional/includes

Currently, we simply branch off new projects from master and everything goes into the same repo. This leads to a branch inflation and my (central) repo grows more and more because all of the commits being made in the single projects go to the central repo (my colleagues are used to SVN, so they push nearly after each commit -- just to be sure...).

First I had in mind were submodules: keep platform as a submodule under a superproject (called super) and then go to super/platform/additional/mystuff, create the sources there and add them to super. But this obviously doesn't work because the files are inside the platform submodule.

Is there any better way to organize my repo, so that:

  • users of the platform are able to update their working copy from the central repo
  • AND users of the platform are able to apply bug fixes to the repo of platform
  • AND the projects using platform don't mess up the repo of platform?

EDIT 1: Highly coupled git submodules covers quite a bit of the scenario I'm in: tightly coupled stuff, me the only one knowing a bit more than absolute basics of git, "Most of the developers have only a very cursory knowledge of git". Perfect match!


EDIT 2:
While the answer from Michael looks promising, I think that it's a bit too complex to use. I'm looking for some really simple thing that doesn't need that much interaction.

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

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

发布评论

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

评论(1

哑剧 2024-12-01 07:05:23

我发现你对 master 的使用有点令人困惑,因为我从来不知道
无论您是指整个平台存储库还是只是其
主分支。

我的解决方案如下:

  • 您有一个平台的中央存储库。
  • 每个项目都有一个中央存储库。
  • 每个开发人员都有他/她自己的本地存储库。

中央平台存储库

这里只有平台代码所在。使用例如您的
现有的回购协议作为起点。

中央项目存储库

这是平台存储库的克隆,并保留所有代码
一个项目的。使用

$ git clone --bare /path/to/platform

开发人员的本地存储库

初始化

它 作为开发人员,您首先要克隆项目存储库。

$ git clone /path/to/project

对项目进行更改

现在,进行更改、提交并将其推送到项目
裸仓库。

$ editor some-file
$ git add -p some-file
$ git commit
$ git push

将其他开发人员所做的更改拉到项目裸存储库中
通过使用 git pull 。

对平台进行更改

由于您还想对平台本身进行更改,因此您还
需要一种访问平台存储库的方法。所以你将它添加为
远程存储库到本地存储库:

$ git remote add platform /path/to/platform
$ git fetch platform

正如您现在使用 gitbranch -a 所看到的,您的本地存储库知道
关于平台。现在您想要对以下内容进行一些更改
平台。首先,您创建一个本地分支central,它是
平台存储库主分支的克隆:

$ git checkout -b central platform/master

您始终可以使用 gitbranch 来检查您所在的分支
git status。现在您进行更改并提交它们(以
中央,你在的地方)。由于中央连接到
platform/master(签出cat .git/config)您可以推送您的
只需使用 git push 即可更改平台存储库。还
git pull 无需任何其他参数即可工作。

使用 git checkout master 和 git checkoutcentral 进行更改
在你的树枝之间。

在您的项目中获取新的平台版本

注意:您需要完成上一部分的工作

首先更改您的平台分支并引入新版本
平台的:

$ git checkout central
$ git pull

现在返回到您的项目分支并合并所做的更改
将平台添加到您的项目分支中。

$ git checkout master
$ git merge central

如果发生冲突,会发生类似的情况:

$ git merge central
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

打开有冲突的文件,解决它们,将它们添加到
暂存区域并提交合并:

$ editor index.html
$ git add index.html
$ git commit

现在将更改推送到项目的裸存储库:

$ git push

有关合并冲突的更多信息:Pro Git:基本合并冲突

如果您不想更改平台存储库,但合并
从那里到您的项目使用的更改

$ git remote add platform /path/to/platform
$ git fetch platform
$ git merge platform/master

仅在第一次合并时才需要 git remote add
另外两个始终是必需的。


关于合并的部分基于Pro Git Book,它是
根据 cc-by-sa 获得许可。这篇文章的所有其他内容可能是
被视为公共领域。

I found your usage of master a bit confusing as I never knew
whether you meant the platform repository as a whole or just its
master branch.

My solution to this would be the following:

  • You have one central repository for the platform.
  • You have one central repository per project.
  • Every developer has his/her own repository local.

The central platform repository

This is where only the platform code goes to. Use e.g. your
existing repo as a starting point here.

The central project repository

This is a clone of the platform repository and keeps all the code
of a project. Init it with

$ git clone --bare /path/to/platform

The developer's local repository

Init

You, as a developer, start by cloning the project repository.

$ git clone /path/to/project

Making changes to the project

Now, make your changes, commit them and push them to the projects
bare repo.

$ editor some-file
$ git add -p some-file
$ git commit
$ git push

Pull changes made by other developers to the projects bare repo
by using git pull.

Making changes to the platform

As you also want to make changes to the platform itself, you also
need a way to access the platform repo. So you add it as a
remote repo to your local repo:

$ git remote add platform /path/to/platform
$ git fetch platform

As you can see now with git branch -a, your local repo knows
about the platform. Now you want to make some changes to the
platform. First you create a local branch central which is a
clone of the master branch of the platform repo:

$ git checkout -b central platform/master

You can always check which branch you're on by using git branch
or git status. Now you make your changes and commit them (to
central, where your on). As central is connected to
platform/master (checkout cat .git/config) you can push your
changes to the platform repo by simply using git push. Also
git pull works without any other arguments.

Use git checkout master and git checkout central to change
between your branches.

Get a new platform version into your project

Note: You need to have done the work from the previous section.

First change to your platform branch and pull in the new version
of the platform:

$ git checkout central
$ git pull

Now go back to your project branch and merge the changes made in
the platform into your project branch.

$ git checkout master
$ git merge central

If a conflict occurs, something like this happens:

$ git merge central
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Open the files with the conflicts, resolve them, add them to the
staging area and commit the merge:

$ editor index.html
$ git add index.html
$ git commit

Now push your changes to the project's bare repo:

$ git push

More about merge conflicts: Pro Git: Basic Merge Conflicts

If you do not want to change the platforms repo, but merge
changes from there into your project use

$ git remote add platform /path/to/platform
$ git fetch platform
$ git merge platform/master

The git remote add is only needed the first time you merge.
The other two are always required.


The part about merging is based on the Pro Git Book which is
licensed under cc-by-sa. All other content of this post may be
considered public domain.

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