我总是在Laravel中使用作曲家包装,但我从不更改。这是我第一次,我不想做不正确。
我需要使用并更改 packages foo/bar
。现在只有以下所有内容都猜到了:
- 我分配了回购
- ,我创建了一个
开发
分支,
- 我将VCS添加到我的
composer.json.json
"require": {
//...
"foo/bar": "dev-develop",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/thisisme/bar"
}
],
-
Composer update
- 现在我在我的
供应商
文件夹中的 thisisme/bar
fork中的 foo
中的文件夹。
到目前为止,一切都很好。现在我可以使用自己的叉子。
但是目前,由于我不知道修改存储库是什么好练习,所以我将存储库克隆到完全不同的位置。然后,我将更改推到那里,并在项目中运行 COMPOSER UPDATE
以获取更改。但这是一个痛苦。
我是否需要在我的项目中使用供应商/foo
的sub git
git Remote添加https://github.com/thisisme/bar.git
。因为“ git in git”感到错误,最后并没有真正起作用,因为git命令似乎与“父git”互动。
I always use composer packages in Laravel but I never changed one. This is my first time and I don't want to do it incorrect.
I need to use and change a packages foo/bar
. Everything that follows now is just guessed:
- I forked the repo
- I created a
develop
branch
- I added a vcs to my
composer.json
"require": {
//...
"foo/bar": "dev-develop",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/thisisme/bar"
}
],
composer update
- Now I have the
thisisme/bar
fork in my vendor
folder in foo
.
So far so good. Now I can use my own fork.
But currently, as I don't know what is good practice to modify the repo, I cloned the repo to a completely different location. Then I push my changes there and run composer update
in my project to get the changes. But this is a pain.
Do I need to have a sub git in my project in vendor/foo
with
git remote add origin https://github.com/thisisme/bar.git
. Because "git in git" feels wrong and finally is not really working as git commands seem to interact with the "parent git".
发布评论
评论(3)
voncs答案在git方面是正确的,我不确定git子模块支持与
code> Composer很好地对齐(1)
供应商
for VCS存储库中包的dir。至少我对此没有太多实验,当我使用VCS Git存储库的作曲家配置时,我通常不需要 1 。Composer(1)
对供应商软件包的Git支持,但它在存储库级别,也就是说,您可以拥有自己的软件包的存储库(如您在问题中所示的那样)和然后,作曲家照顾更新(或对本地更改发出警告)。COMPOSER(1)
用自己的遥控器(非BARE)克隆(在source> source
install,请继续)中支持这一点。因此,是的,您描述的内容(“但这是一个痛苦。” ),只要您不利用它来利益。在开发(克隆)软件包时,您无需始终运行
COMPOSER UPDATE
。一个具有两个git存储库的作曲家项目
这就是为什么恕我直言的“ git in git in git”不得感到错误的原因。与GIT子模型类似,Git很好地支持了这一点。默认情况下,它甚至可以在子项目的当前修订(更改)的父项目中跟踪,但没有远程信息的信息 - 因为它是局部的( gitlink )。
您不会在树中看到这个想法, gitlink 将在
供应商/foo/bar
和通常(&给定)供应商被忽略,在主项目中没有版本跟踪
供应商/foo/bar/.git
- 但是在子项目中。这不是一个问题,因为作曲家在您的主要项目方面管理了为您(初始克隆和进一步结帐)进行git子项目的问题。
Git意识到这是一个不同的项目。
您应该能够在供应商文件夹(
供应商/foo/bar
)中cd
进入包装目录,并在此处配置远程(s)。然后,您可以在该项目中工作,并且git(1)
将在那里工作,而父母存储库中的不。要使用
Composer(1)
进行此工作,因此,您必须配置作曲家,才能更喜欢该存储库的 source install 变体。这是prefinred-install
选项您可以为您的存储库配置它。从您的问题中的措辞中,我认为您尚未配置它。
这仅在
source
install上,这一点很重要,vendor/foo/bar
供应商
目录中的包装文件夹中的总体git配置(因为您将GitHub配置为存储库来源和Composer优化,以默认使用dist
版本。将配置更改为
source
安装并更新它后,cd
<代码>供应商/foo/bar ,然后运行git Remote- V
。现在,它应该向您显示该软件包的“作曲家”遥控器。当您使用
开发
分支时,您可以在本地添加更改,但请注意,在您再次使用Composer再次更新(至少)之前,您也需要将它们推入远程存储库(GitHub)(GitHub)foo/bar
软件包 - 当您使用git
用于开发foo/bar
软件包时,在您的主项目中,您使用作曲家
管理依赖关系。这是您使用github而不是更接近工作地点的配置上的薪资的价格,但是至少在本地,您可以使用“ git in git in git”处理包裹。
这通常是直截了当的。由于管理两个存储库,但您无法阻止这种作曲家项目(仅作曲家版本的供应商文件夹))。
在 从VCS存储库中加载软件包 。
1 有一种用于作曲家项目的设置,其中
供应商
本身在GIT版本控制下,而Git子模块可以工作(很好),但这是很可能不是您为项目设置的设置,因此我跳过此答案。While VonCs answer is correct regarding git, I'm not certainly sure that git submodule support is well aligned with
composer(1)
vendor
dir for packages from a VCS repository. At least I have not experimented much with it and when I use a composer configuration with a VCS git repository, I normally don't need that1.While
composer(1)
has support for git for vendor packages, it is on repository level, that is, you can have your own repository for your package (as you have configured it shown in your question) and then composer takes care of updating (or giving a warnings about local changes).composer(1)
supports this with its own remote for the packages (non-bare) clone (in thesource
install, read on).So yes, what you describe ("But this is a pain."), is as long as you don't use it to your benefit. While you develop your (cloned) package, you don't need to run
composer update
all the time.A Composer project with two Git repositories
This is why IMHO "git in git" must not feel wrong. Similar to git sub-modules, git supports this very well. By default it even keeps track in the parent project of the current revision (changes) of the sub-project but without having the information of the remote - as it is local (gitlink).
You won't see this thought as within the tree, the gitlink would be at
vendor/foo/bar
and commonly (& given that)vendor
is git ignored, no version tracking in the main project forvendor/foo/bar/.git
- but there in the sub-project.This is not a problem as Composer manages that git sub-project for you (the initial clone and further checkouts) in terms of your main project.
And git realizes it is a different project.
You should be able to
cd
into the package directory within the vendor folder (vendor/foo/bar
) and configure your remote(s) there. You can then work within that project andgit(1)
will work there and not within the parent repository.To have this work with
composer(1)
it is important that you configure composer to prefer the source install variant for that repository. This is thepreferred-install
option and you can configure it for your repository specifically.From the wording in your question, I assume that you have not yet configured it.
And this is somewhat important as only with the
source
install, there will be a (non-bare) git clone invendor/foo/bar
and therefore the git checkout with the overall git configuration within the packages folder in thevendor
directory (as you have Github configured as the repository source and composer optimizes to take thedist
version by default IIRC).After you changed your configuration to the
source
install and updated it,cd
intovendor/foo/bar
and then rungit remote -v
. It now should show you the "composer" remote(s) for that package.As you use the
develop
branch, you can add changes locally but mind the gap that you would also need to push them to the remote repository (Github) before you use composer again to update (at least) thatfoo/bar
package - as while you usegit
for the development of thefoo/bar
package now, in your main project you usecomposer
to manage the dependency.This is the price you have on the payroll using Github instead of a configuration that is more near to the place of work, but at least locally, you can handle the package with "git in git".
This is normally straight forward. One overall price remains thought, due to managing two instead of one repository but that you can't prevent with this kind of composer project [composer only versioned vendor folder]).
A bit of a workflow with some hints is also outlined in the composer documentation in Loading a package from a VCS repository.
1 There is a type of setup for a composer project where
vendor
itself is under git version control, with that git sub-modules can work (very well), but this is most likely not the kind of setup you have for your project, so I skip it for this answer.如果您正在使用帆船或码头组合并链接供应商dir中的foo/bar项目,这只是临时的,直到“它可以使用”解决方案,则可以将其添加为音量链接。这是我通常要做的。
例如:我正在研究
〜/projects/my-project
中的my-project,我克隆foo/bar
repo repo〜/projection/bar < /code>
然后在docker-compose.yml中我可以添加卷:
同样,这对使用的码头有一个巨大的假设,但是我想认为这些天每个人都在使用它。
If you're working with sail or docker-compose and linking the foo/bar project in the vendor dir is only a temporary until 'it works' solution you could just add it as a volume link. This is what I usually do.
Eg: I'm working on my-project in
~/projects/my-project
, I clone thefoo/bar
repo to~/projects/bar
Then in the docker-compose.yml I can add the volume:
Again, this has a huge assumption on docker being used, but I like to think that everybody is using it these days.
可以用 subpodule git存储库仅存储参考到另一个存储库。
You would use
a 因此,将您的项目用suppoule git存储库克隆到克隆中,并签出您先前提交的确切参考。
That could be achieved with a submodule which allows for your parent Git repository to only store a reference to another repository.
You would use
git submodule add
for that.A
git clone --recurse-submodule
would therefore clone your project with the submodule Git repository in it cloned as well, and checked out to the exact reference you previously committed.