自动将 git 存储库中的一个文件夹的更改推送到 github？
我有一个工作的存储库。其中有一个文件夹，我把所有想要开源的东西都放在其中，因此它与私有部分分开。有没有一种方法可以自动让 git 将提交到该文件夹的任何内容推送到 github 存储库，而不必记住每次都将新更改的文件推送到那里？我想将整个存储库推送到另一个 github 位置。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您有一个存储库，其中部分是公共的，部分是私有的，那么您需要从根本上更改存储库设置中的某些内容。 git 跟踪完整的存储库，因此您可以将存储库设为公共或私有，但不能部分这样、部分那样。
如果您同时拥有包含“公共”文件的存储库和包含“私有”文件的存储库，则可以将 git hook 添加到“公共”存储库以自动推送提交，并保持私有存储库私有。
但是，您写道，您有一个包含“公共”和“私有”文件的存储库，因此您需要以某种方式将其拆分为“公共”和“私有”。
您有多种选择来解决此问题情况：
将“public”文件夹拆分到您自己的存储库中
将推送到github。这将稍微重写“public”文件夹的历史记录。
我将在下面更详细地概述这一点。
创建一个仅涉及“public”文件夹的分支，
并且只发布该分支。
从“意外推送，即发布私人内容”的意义上来说，这是有风险的，
如果你有的话，这是完全不可能的，或者至少很难做到
任何涉及“公共”和“私人”文件的提交，所以我会
建议不要使用此选项，并且不会写更多相关内容。
要将“public”文件夹拆分到自己的存储库中，请从“组合”分支创建一个新的“public”分支，并使用
git filter-branch，使新的“public”分支仅包含“public”文件夹中的内容。 “示例”部分显示了正确的 --subdirectory-filter 示例）。然后，您将拥有旧的“组合”分支，其中包含“公共”文件夹和私有内容，以及新的“公共”分支，其中仅包含“公共”文件夹。请注意，例如新“公共”分支中的提交消息仍然可能包含“私有”信息。因此，您应该检查所有提交消息，扫描它们以获取私人信息，并可能编辑该私人信息，例如使用
git rebase -i。现在您的“公共”分支已准备好发布。为了确保它只包含“公共”信息，您可以将其推送到新的空本地裸存储库中，检查其内容以验证所有引用都没有私人信息。满意后，您可以将“public”分支推送到 github 上的新空存储库。 github 上的存储库将仅包含“public”分支，您可能应该在 github 存储库上将其命名为“master”。
具有“组合”分支的本地存储库仍然直接包含公共和私有信息，并且与新的“公共”github 存储库没有任何连接。
现在您可以重写“组合”分支的历史记录以仅包含非公共位，但这会牺牲所有历史记录中“公共”和“私有”文件状态之间的所有连接，因此，旧东西的可重复构建几乎是不可能的。因此，我建议保留“组合”分支的历史记录，并在新提交中从中删除“公共”文件夹。
如果您的私有文件和公共文件之间的集成非常紧密并且依赖于版本，您可以使用
git 子模块将 github 中的“公共”存储库的特定版本添加到您的私有存储库中。与以前的“公共”文件夹一样命名的新子模块文件夹将最大限度地减少对私有内容的更改，因为所有“公共”文件都将位于其旧路径中。请注意，当某些内容被推送到 github 时，子模块文件夹不会自动更新。您可以通过向本地子模块文件夹添加 git hook 来解决这个问题，这将更新“组合”存储库中的子模块信息。如果您的私人文件和公共文件之间的集成更加松散，您还可以像任何外部第三方项目一样对待公共文件，并以其他人集成它的方式将其集成到您的私人文件中，即像任何外部文件一样您的“私有”软件所依赖的软件。
If you have a single repository where parts are intended to be public and parts are intended to be private, then you need to fundamentally change something in your repository setup. git tracks complete repositories, so you can either make a repository public or private, but not partly this and partly that.
If you have both a repo with the "public" files and a repo with the "private" files, you can add a git hook to the "public" repo to automatically push commits, and just keep the private repo private.
However, you are writing that you have a single repo containing both "public" and "private" files, so you need to split that into something "public" and something "private in some way.
You have a number of options to solve this situations:
Split out the "public" folder into its own repository which you
will push to github. This will rewrite the history of the "public" folder a little.
I will outline this in more detail below.
Create a branch that only concerns the "public" folder,
and only publish that branch.
This is risky in the "accidentally push, i.e. publish, private stuff" sense,
and outright impossible or at least quite difficult to do if you have
any commits that touch both "public" and "private" files, so I would
advise against this option, and will not write more about it.
For splitting off the "public" folder into its own repository, create a new "public" branch off your "combined" branch, and use
git filter-branchon it to make the new "public" branch contain only stuff from the "public" folder. The "Examples" section shows just the right --subdirectory-filter example). Then you will have both your old "combined" branch with both the "public" folder and the private stuff in it, and the new "public" branch with only the "public" folder.Be aware that e.g. the commit messages in the new "public" branch still might contain "private" information. So you should go through all the commit messages, scan them for private information, and possibly redact out that private information, e.g. with
git rebase -i.Now your "public" branch is ready for publication. To make sure it only contains the "public" information, you can push it into a new empty local bare repo, examine the content of that to verify all refs have no private information. After you are satisfied, you can push the "public" branch to a new empty repo on github. The repo on github will then ONLY contain the "public" branch, which you should probably name "master" on the github repo.
Your local repo with the "combined" branch still contains both public and private information directly, and has no connection to the new "public" github repo whatsoever.
Now you could rewrite the "combined" branch's history to just contain the non-public bits, but that would sacrifice all connections between the state of "public" and "private" files during all of the history, so repeatable builds of old stuff would become close to impossible. Therefore, I suggest to leave the "combined" branch's history alone, and just remove the "public" folder from it in a new commit.
If the integration between your private and your public files is very tight and version dependent, you can use
git submoduleto add a specific version of the "public" repo from github into your private repo. A new submodule folder named just like the former "public" folder will minimize the changes to your private stuff, as then all "public" files will be in their old path. Note that the submodule folder will not update automatically when something has been pushed to the github. You might work around that by adding a git hook to your local submodule folder which would update the submodule information in the "combined" repo.If the integration between your private and your public files is more loose, you can also treat the public files like any external third-party project and integrate it into your private stuff in the way anybody else would integrate it, i.e. like any external piece of software your "private" software depends on.
使用 githook 推送提交。
Use a githook to push on commit.