git - 如何将对子模块所做更改的提交推送到主 git repo？

Question

我已决定将我的应用程序存储库从 SVN 切换到 git。

我的仓库结构是这样的:

~/AndroidStudioProjects/MyMine $ tree -L 1
.
├── ActionBarSherlock
├── Android-Universal-Image-Loader
├── Android-ViewPagerIndicator
├── Crouton
├── ListViewAnimations
├── MyMine
├── SlidingMenu
├── aFileChooser
├── drag-sort-listview
└── out

10 directories, 0 files

如您所见，我有很多库，我的应用程序的核心位于 MyMine 文件夹中。

我已将这些库添加为 git 子模块:

~/AndroidStudioProjects/MyMine $ cat .gitmodules
[submodule "ActionBarSherlock"]
    path = ActionBarSherlock
    url = https://github.com/JakeWharton/ActionBarSherlock.git
[submodule "Android-Universal-Image-Loader"]
    path = Android-Universal-Image-Loader
    url = https://github.com/nostra13/Android-Universal-Image-Loader.git
[submodule "Android-ViewPagerIndicator"]
    path = Android-ViewPagerIndicator
    url = https://github.com/JakeWharton/Android-ViewPagerIndicator.git
[submodule "Crouton"]
    path = Crouton
    url = https://github.com/keyboardsurfer/Crouton.git
[submodule "drag-sort-listview"]
    path = drag-sort-listview
    url = https://github.com/bauerca/drag-sort-listview.git
[submodule "ListViewAnimations"]
    path = ListViewAnimations
    url = https://github.com/nhaarman/ListViewAnimations.git
[submodule "SlidingMenu"]
    path = SlidingMenu
    url = https://github.com/jfeinstein10/SlidingMenu.git
[submodule "aFileChooser"]
    path = aFileChooser
    url = https://github.com/iPaulPro/aFileChooser.git

现在，假设我对其中一个库/子模块进行了更改。但我不想将这些更改推到它们的源头，因为:

• 作者可能/将拒绝我的 promise
• 我的更改只与我相关
• 我的更改只是修改代码以使其在我的项目中编译的一行修改

但是，我做想要的是将我的提交(对那些子模块所做的)推送到我的项目的来源。这是因为这些更改是编译我的项目所必需的。因此，如果我决定例如将完整的 repo 克隆到新的开发机器，我希望它们在 repo 中。或者，如果一个新人加入团队并需要设置其开发机器。

那么，我已经提交了对其中一个库所做的修改。然后，我将相应的子模块提交到我的存储库，并将其推送到源。

问题是在(我的服务器的)origin 上，子模块项目指向错误的快照，因为该快照仅存在于我的本地 repo 上，而不存在于 origin 的。而且我不能推送它，因为 git 会尝试将提交推送到子模块的来源，这不是我项目的来源。

我如何提交对子模块所做的更改，并从我的主存储库中获得这些更改？所有这些都没有将子模块推回原点？

如果我使用的术语或方法看起来愚蠢或不合适，我深表歉意。正如我所说，我正在尝试切换到 git，即使我花了一些时间阅读一本 git 书，我也可能误解了一些流程或词汇。

Answer 1

据我所知，你不能那样做。

您需要 fork 子模块存储库并将项目的子模块指向 fork 而不是当前位置。然后您可以将您的更新推送到您的分支，并在那里维护它们，并且您的主项目可以指向您的更改。

您的另一个选择是将您的更改作为补丁进行维护，并让您的构建系统在编译之前应用它们。

也许有人会为您带来巧妙的把戏。