仅将某些代码推送到不同的存储库
我有一个 Codeigniter 项目，需要两个不同的存储库：一个用于与我的团队进行本地开发 (bitbucket)，另一个用于在我的客户端进行部署 (gitlab)。我正在寻找简化从一个存储库到另一个存储库的更改的方法。
我的问题：对于本地开发，我需要不想推送到客户端服务器的文件（composer、package.json，...），反之亦然（deploy.php、来自 gitlab-ci 的 yml 文件），但是大多数文件是相同的，仅由我和我的团队更改。
根据我的阅读，简单地添加第二个 git-remote 是行不通的，因为我不能有两个 gitignore 文件。我从未使用过 git 子模块，但据我了解，它需要子文件夹，并且存储库之间不同的文件需要位于根目录中。我的理解正确吗？
有没有办法只向某些方向/远程仓库推送某些文件？
I have a Codeigniter project that needs two different repos: one for local development with my team (bitbucket) and one on my client's side for deployment (gitlab). I am looking for ways to simplify getting changes from one repo to the other.
My issue: For local development, I need files which I don't want to push to the clients server (composer, package.json, ...) and vice versa (deploy.php, yml files from gitlab-ci), but the majority of the files is the same and only changed by me and my team.
From what I have read, simply adding a second git-remote wouldn't work because I couldn't have two gitignore files. I have never worked with git submodules, but from what I understand, it would require subfolders and the files that differ between the repos need to be in the root directory. Have I understood this correctly?
Is there a way to push only certain files in certain directions/remote repos?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不。但是您的假设是错误的：Git 推送文件。事实并非如此。 Git 根本不存储文件，真的。相反，Git 存储提交。每次提交：
因此，每次提交都会存储文件，但使用 git push 传输的不是单个文件，而是整个提交。
存储库本质上只是两个数据库：
第一个也是通常最大的数据库包含提交和其他支持对象。通常，您选择一个特定的提交（使用其哈希 ID，但查看下一点）并使用 git checkout 来“检查”它，或者使用 git switch 来“切换”到它>。这会从特定提交中提取所有文件，并且现在您就拥有了文件。但在执行这一步之前，您所拥有的只是提交。好吧，提交、支持对象，还有……
第二个数据库包含名称：分支名称、标记名称和各种其他名称。这些名称中的每一个都拥有一个哈希 ID；特别是分支名称总是保存提交哈希ID（某些名称可以并且有时确实保存支持对象的哈希ID，然后导致可用的提交）。
如果您有两个存储库，那么您只需拥有其中两对数据库。如果您希望设置一个区域，其中的文件是从两个不同存储库中的两次不同提交中提取的文件，但合并到一个混合区域中，您可以这样做，但事实并非如此Git 擅长的东西。 Git“喜欢”工作区域包含一个存储库中一次提交的文件。这样，您所做的任何更改都可以通过简单的
git add和git commit存储到该（一个）存储库中的新提交中。不要使用 Git 本身将两组文件混合在一起。相反，设置两个单独的 Git 存储库，分别在它们中工作，并使用您获取或编写的一些附加软件来读取两个单独的 Git 工作区域（或直接从两个存储库中进行单独提交），并将它们与任何内容混合在一起你喜欢的规则。这可能会变得复杂。例如，考虑一下当左侧的快照 L 包含文件
A、B和C/D，右侧的快照 R 包含文件B、F和C。B的两个版本中只有一个可以出现在混搭位置中。而且，如果文件C出现在混搭在一起的位置，您可能不能同时拥有文件夹C> 包含文件D。 （这种复杂性是 Git 不这样做的部分原因。）No. But you're starting from an incorrect supposition: that Git pushes files. It doesn't. Git does not store files at all, really. Instead, Git stores commits. Each commit:
Each commit therefore stores files, but what you transfer with
git pushis not individual files, but rather entire commits.A repository is, at its heart, just two databases:
The first and usually largest database contains the commits and other supporting objects. Typically you pick one particular commit—using its hash ID, but see the next point—and "check it out" with
git checkout, or "switch" to it withgit switch. This extracts all the files from that particular commit, and now you have files. But until you do this step, all you have are the commits. Well, the commits, the supporting objects, and...The second database contains names: branch names, tag names, and various other names. Each of these names holds a hash ID; branch names in particular always hold commit hash IDs (some names can and sometimes do hold hash IDs of supporting objects, which then lead to usable commits).
If you have two repositories, you simply have two of these pairs of databases. If you wish to set up an area in which you have files that are extracted from two different commits in two different repositories, but into a single mingled-together area, you can do that, but that is not something that Git is good at. Git "likes" for the working area to contain the files from one commit in one repository. That way any changes you make can be stored into a new commit in that (one) repository with a simple
git addandgit commit. Don't use Git itself to mash two sets of files together. Instead, set up the two separate Git repositories, work in them separately, and use some additional software you obtain or write, to read the two separate Git work areas (or individual commits directly out of the two repositories) and mash them together with whatever rules you like.This may get complicated. Consider, e.g., that you will need to decide what to do when snapshot L, on the left, contains files
A,B, andC/D, and snapshot R, on the right, contains filesB,F, andC. Only one of the two versions ofBcan appear in the mashed-together location. And, if fileCis to appear in the mashed-together location, you probably cannot also have a folderCcontaining a fileD. (This kind of complication is part of why Git does not do this.)