如何在fork的供应商文件夹中使用git?

发布于 2025-02-03 06:34:50 字数 932 浏览 4 评论 0 原文

我总是在Laravel中使用作曲家包装,但我从不更改。这是我第一次,我不想做不正确。

我需要使用并更改 packages foo/bar 。现在只有以下所有内容都猜到了:

  1. 我分配了回购
  2. ,我创建了一个开发分支,
  3. 我将VCS添加到我的 composer.json.json
  "require": {
    //...
    "foo/bar": "dev-develop",
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/thisisme/bar"
    }
  ],
  1. Composer update
  2. 现在我在我的供应商文件夹中的 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:

  1. I forked the repo
  2. I created a develop branch
  3. I added a vcs to my composer.json
  "require": {
    //...
    "foo/bar": "dev-develop",
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/thisisme/bar"
    }
  ],
  1. composer update
  2. 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".

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

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

发布评论

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

评论(3

浅沫记忆 2025-02-10 06:34:50

voncs答案在git方面是正确的,我不确定git子模块支持与 code> Composer很好地对齐(1) 供应商 for VCS存储库中包的dir。至少我对此没有太多实验,当我使用VCS Git存储库的作曲家配置时,我通常不需要 1

Composer(1)对供应商软件包的Git支持,但它在存储库级别,也就是说,您可以拥有自己的软件包的存储库(如您在问题中所示的那样)和然后,作曲家照顾更新(或对本地更改发出警告)。

COMPOSER(1)用自己的遥控器(非BARE)克隆(在 source> source install,请继续)中支持这一点。

因此,是的,您描述的内容(“但这是一个痛苦。” ),只要您不利用它来利益。在开发(克隆)软件包时,您无需始终运行 COMPOSER UPDATE


.git
composer.json
vendor/foo/bar/.git

一个具有两个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 选项您可以为您的存储库配置它。

{
    "config": {
        "preferred-install": {
            "foo/bar": "source"
        }
    }
}

从您的问题中的措辞中,我认为您尚未配置它。

这仅在 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”处理包裹。

这通常是直截了当的。由于管理两个存储库,但您无法阻止这种作曲家项目(仅作曲家版本的供应商文件夹))。

注意: 如果开发需要比几个小时更长的时间,则在您的育儿项目的备份例程中包括新的GIT子项目,因此,当您删除文件夹供应商/foo/bar 时,您会备份(本地)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 the source 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.


.git
composer.json
vendor/foo/bar/.git

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 for vendor/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 and git(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 the preferred-install option and you can configure it for your repository specifically.

{
    "config": {
        "preferred-install": {
            "foo/bar": "source"
        }
    }
}

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 in vendor/foo/bar and therefore the git checkout with the overall git configuration within the packages folder in the vendor directory (as you have Github configured as the repository source and composer optimizes to take the dist version by default IIRC).

After you changed your configuration to the source install and updated it, cd into vendor/foo/bar and then run git 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) that foo/bar package - as while you use git for the development of the foo/bar package now, in your main project you use composer 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]).

Note: If development takes longer than a few hours, it may also make sense to include the new Git sub-project in the backup routine of your parenting project, so that when you remove the folder vendor/foo/bar you have a backup of the (local) Git repository and working tree in it. However, this depends on the project configuration and is your own responsibility.


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.

乖乖公主 2025-02-10 06:34:50

如果您正在使用帆船或码头组合并链接供应商dir中的foo/bar项目,这只是临时的,直到“它可以使用”解决方案,则可以将其添加为音量链接。这是我通常要做的。

例如:我正在研究〜/projects/my-project 中的my-project,我克隆 foo/bar repo repo 〜/projection/bar < /code>

然后在docker-compose.yml中我可以添加卷:

volumes:
      - .:/var/www/html
      - ../bar:/var/www/html/vendor/foo/bar

同样,这对使用的码头有一个巨大的假设,但是我想认为这些天每个人都在使用它。

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 the foo/bar repo to ~/projects/bar

Then in the docker-compose.yml I can add the volume:

volumes:
      - .:/var/www/html
      - ../bar:/var/www/html/vendor/foo/bar

Again, this has a huge assumption on docker being used, but I like to think that everybody is using it these days.

豆芽 2025-02-10 06:34:50

我是否需要在供应商/foo中使用git Remote添加aDREANT https ://github.com/thisisme/bar.git

可以用 subpodule git存储库仅存储参考到另一个存储库。
You would use

a 因此,将您的项目用suppoule git存储库克隆到克隆中,并签出您先前提交的确切参考。

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.

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.

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