Rebase from commit

Question

我有一个框架，我编码，它是一个Github存储库，作为主分支。进入该分支只是框架的核心文件，所以我将其命名为核心分支。 现在进入其他分支机构，我列出了使用上述核心框架的项目 - 我这样做是因为虽然使用分支机构会更容易，但正如我刚刚发现的，事实并非如此。认真。

所以总结一下：我有一个核心分支和项目分支使用该内核。现在在项目分支，我做的主要是提交有关项目（添加图像X，修改样式表Y），但有时我修改核心，使其更好。

现在我想要做的，再一次我认为这很简单，就是当我开始研究核心而不是项目时，将核心更改合并到核心分支中。 有几个解决方案，这一切都开始混淆我，因为我不想搞乱我的核心分支，我应该如何继续？

我知道我可以选择提交并推送它，但我真的想保留核心文件更改的历史记录，所以我一直被引导到rebasing。 问题是：如果我将核心分支重定义为项目分支上的特定提交，它将推送与核心无关的所有文件和内容。那么如何将从分配给某个提交（而不是到，这似乎是默认设置？）。

这是某种对项目分支什么承诺可能看起来像的想法：

项目分支

00:12 - Added image X 
00:14 - Modified stylesheet Y to have a pink background (pink is pretty) 
00:16 - Modified class core.background to handle pink background 
00:18 - Modified class core.string to always capitalize Pink (because it's so pretty) 

如何最后两次提交合并为核心分支没有合并两个与项目有关的第一个，并保留历史 - 即。将这两个变化作为两个提交而不是一个提交？

---

编辑：更多精度。 我的核心框架定义了一个项目的文件夹组织，因此需要位于项目文件夹的根目录下。这就是为什么它不是一个子模块，这本来就是梦想。 另外，我尝试了核心的分支，但显然你不能分叉你自己的项目。

如果除了分支之外还有另一种方式来做我想做的事，我全都是耳朵。

Answer 1

git分支机构并不像这样 - 分支机构都与存储库相关。将项目或项目的一部分分离成单独的分支并不是真正的正确途径。最后，大多数分支应合并成某种类型的release分支，或者丢弃。

我有一个核心分支和一个使用该核心的项目分支。现在在项目分支上，我主要提交与该项目相关的内容......

我真的很想继续更改核心文件[单独]

从这个历史，我觉得这听起来很像你有两个不同的版本库，一个良好的使用情况为core-files和一个为project - 你想保持core和project的历史分开。我建议将core-files拉到projects的git submodule，而不是将它们保存在不同分支的同一个存储库中。这会给你几个优点：

• project和core历史是分开的。
• 使用core与另一个项目很简单;输入core作为otherproject的git submodule。
• project和core的历史很多，更容易维护，因为您不必在分支之间挑选。