我们会将一个项目分叉到它自己的代码库中，但它会密切关注它所分叉的项目。
我看到它是这样工作的：
分叉项目将开发一些初始更改以重新命名产品。我不想与原始项目共享这些更改，但我想合并更改。
我们设置它的方式是现在具有相同历史记录的单独存储库，只需为彼此添加遥控器。
我想到的工作流程是这样的：
我们应该尝试在功能分支上工作，并且每个功能只有 1 次提交，这样我们每个人都可以 git cherry-pick 。每当您处理某个功能并提交时，只需在该功能的分支中执行 git commit --amend 即可。当它最终确定时，我可以挑选提交。
我不喜欢这样，因为如果在挑选樱桃后特性发生变化，开发人员需要记住不是结束而是创建一个新的提交。
我很想通过合并或变基来做到这一点。
一种可能的构建方式是使用三个存储库，其中一个存储库是“白标版本”，另外两个存储库用于两个前端。两个前端将引用“白标版本”存储库作为子模块。
使用这种结构，您：
如果您的两个前端将相似，那么它们可以是一个存储库的分支（但都依赖于子模块）。在这种情况下，如果您在两个前端之间来回合并，一个好的方法是为每个特征创建一个分支。每个功能都有一个分支可以让您摆脱“每个分支一次提交”的限制。<branch-base>..<branch-head>[编辑] 根据特性分支的性质，您可以 a) 使用;挑选所有提交 或 b) 将分支上的所有内容重新设置为一个提交，然后选择该提交或 c) 使用合并/重新设置将功能分支到另一个分支（请参阅git rebase文档中的众多示例，尤其是--onto选项。） [/编辑]
这里还有一个常见的、备受推崇的分支模型，其中讨论了特性分支。
[edit2] 如果您愿意，您可以使用一个存储库来执行此操作。保留三个主要分支：white-label-dev、prod1-dev、prod2-dev，并让三个团队中的每个团队的开发人员只在他们的分支上操作，或者在他们的分支之外创建的分支上操作。当一个团队有一些应该共享的东西时，“企业集成负责人”将负责将提交从一个团队的工作转移到另一个团队的分支。（如上所述移动提交。）
您的团队将需要一些纪律，以避免与另一个团队的分支机构发生冲突。但是，如果您有一个共享存储库，您可以分配挂钩以防止来自错误团队的推送到另一个团队的分支。[/编辑2]
建议的工作流程：
git merge --squash -m 'new feature' branchname
现在，删除分支！
git branch -D branchname
下一次合并将在主分支上显示为不同的提交。
我认为您希望遵循 Github 用于保持分叉项目更新的类似程序。
首先是whitelabel回购。这是其他项目将分叉的项目。然后其他项目将是设置为repowhitelabel的克隆。使用它，您将能够执行或取决于工作流程。whitelabelupstreamgit merge upstream/mastergit rebase upstream/master
优点是您不必直接了解主要项目的状态。其他项目成为他们自己的分支，可以轻松更新。尝试cherry-pick更改可能很容易变得繁重，尤其是在提交很多的情况下。如果其他项目之一想要对来自原始存储库的代码进行更改，则执行此操作，您可以更轻松地管理该更改。
http://www.techblogistech.com/2012/07/setting-a-default-upstream-branch-in-git/
请参阅此处有关拉入更改的部分： https ://help.github.com/articles/fork-a-repo
如果叉子应该跟随叉子的脚步，最好将叉子保存在主存储库的分支中。否则，挑选上游变化等将变得不必要地困难。
考虑分叉存储库的好处/成本。保持在一起只是意味着拖着差异（可能很小？）。
如果需要，您可以使用gitolite控制对分支的访问。
假设您的品牌代码都可以“干净”地驻留在views/目录中，我建议将视图拆分为自己的 git 存储库并将其嵌套在您的主项目中。看这里
然后，您可以选择
我更喜欢 1. 因为我预计部分视图可能需要通过将它们折叠回白标或从白标中挑选到品牌上来共享。
白标项目布局；
- app_whitelabel/ <<-- clone of "app" repo on default branch
+ config/
+ controllers/
+ errors/
+ views/ <<-- nested clone of "views" repo on branch "brand1"
品牌1项目布局；
- app_brand1/ <<-- clone of "app" repo on default branch
+ config/
+ controllers/
+ errors/
+ views/ <<-- nested clone of "views" repo on branch "brand1"
品牌 [n] 项目布局；
- app_brand2/ <<-- clone of "app" repo on default branch
+ config/
+ controllers/
+ errors/
+ views/ <<-- nested clone of "views" repo on branch "brand[n]"
假设您可以控制两个存储库，则解决方案很简单。
维护每个功能的分支。
维护一个功能发布分支。
功能完成后，将功能分支合并到发布分支并标记它。
如果该功能需要修复错误，请在功能分支中修复它，然后重新合并并使用新版本重新标记它。
您的功能发布分支是您可以集中挑选更新功能或错误修复的地方。您可以通过标签轻松识别您拥有的功能版本。
您还可以轻松查看功能发布分支上的提交历史记录，以查看是否有任何更新。
除了这些分支之外，我还维护一个版本发布分支。任何公开发布的内容都是 QAd 然后提交到版本发布分支。
每个人的本地工作存储库都可以不受限制地拥有他们想要或需要的任意数量的提交。
主存储库具有明确划分的分支，具有明确分段的提交，这些提交不断合并到功能发布和版本发布中。
任何分支都可以通过遵循功能发布分支或版本发布分支轻松更新。在他们想要的任何时候，分叉的回购都可以抓住合适的东西。
黄色分支是标记的功能发布分支，绿色是版本发布分支。叉子可以自由地从其中任何一个分支中拉出，并且确切地知道他们用樱桃镐得到了什么。工作特性分支都基于发布分支，除非它们相互依赖。错误修复与发布分开处理。
就像我说的那样……所有开发人员都有自己的工作存储库，并且可以自由地提交这些存储库。