如何组织我的 Git 存储库
我面临以下问题,但没有答案:
我们有一个从 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 ofplatform
?
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我发现你对
master
的使用有点令人困惑,因为我从来不知道无论您是指整个平台存储库还是只是其
主分支。
我的解决方案如下:
中央平台存储库
这里只有平台代码所在。使用例如您的
现有的回购协议作为起点。
中央项目存储库
这是平台存储库的克隆,并保留所有代码
一个项目的。使用
开发人员的本地存储库
初始化
它 作为开发人员,您首先要克隆项目存储库。
对项目进行更改
现在,进行更改、提交并将其推送到项目
裸仓库。
将其他开发人员所做的更改拉到项目裸存储库中
通过使用 git pull 。
对平台进行更改
由于您还想对平台本身进行更改,因此您还
需要一种访问平台存储库的方法。所以你将它添加为
远程存储库到本地存储库:
正如您现在使用 gitbranch -a 所看到的,您的本地存储库知道
关于平台。现在您想要对以下内容进行一些更改
平台。首先,您创建一个本地分支central,它是
平台存储库主分支的克隆:
您始终可以使用 gitbranch 来检查您所在的分支
或
git status
。现在您进行更改并提交它们(以中央,你在的地方)。由于中央连接到
platform/master(签出
cat .git/config
)您可以推送您的只需使用 git push 即可更改平台存储库。还
git pull
无需任何其他参数即可工作。使用 git checkout master 和 git checkoutcentral 进行更改
在你的树枝之间。
在您的项目中获取新的平台版本
注意:您需要完成上一部分的工作。
首先更改您的平台分支并引入新版本
平台的:
现在返回到您的项目分支并合并所做的更改
将平台添加到您的项目分支中。
如果发生冲突,会发生类似的情况:
打开有冲突的文件,解决它们,将它们添加到
暂存区域并提交合并:
现在将更改推送到项目的裸存储库:
有关合并冲突的更多信息:Pro Git:基本合并冲突
如果您不想更改平台存储库,但合并
从那里到您的项目使用的更改
仅在第一次合并时才需要
git remote add
。另外两个始终是必需的。
关于合并的部分基于Pro Git Book,它是
根据 cc-by-sa 获得许可。这篇文章的所有其他内容可能是
被视为公共领域。
I found your usage of
master
a bit confusing as I never knewwhether you meant the platform repository as a whole or just its
master branch.
My solution to this would be the following:
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
The developer's local repository
Init
You, as a developer, start by cloning the project repository.
Making changes to the project
Now, make your changes, commit them and push them to the projects
bare repo.
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:
As you can see now with
git branch -a
, your local repo knowsabout 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:
You can always check which branch you're on by using
git branch
or
git status
. Now you make your changes and commit them (tocentral, where your on). As central is connected to
platform/master (checkout
cat .git/config
) you can push yourchanges to the platform repo by simply using
git push
. Alsogit pull
works without any other arguments.Use
git checkout master
andgit checkout central
to changebetween 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:
Now go back to your project branch and merge the changes made in
the platform into your project branch.
If a conflict occurs, something like this happens:
Open the files with the conflicts, resolve them, add them to the
staging area and commit the merge:
Now push your changes to the project's bare repo:
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
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.