我正在开发一个产品，代码在github上维护，在master上进行分支和连续合并。
现在，产品必须分成平行的开发：基本上，我将有两个共享共同基础的产品，但每一个都将单独发展。
当然，公共基础也会自行发展，添加新功能并纠正发现的错误。
一个结构将类似于这个：
/P1--P2--P3--P4---/P5--P6----/P7
master --A--B--C--D--------------E----------F
Q1--Q2--Q3----Q4--Q5----Q6
因此，问题是：如果我有两个平行的分支，我如何将它们与我将对公共基线(主(进行的更改合并，而不混合p和Q的开发。
这取决于您的代码库是单片的，还是可以将公共库分解为共享库。
单片代码库
如果这是单片码基；公共基础"；不能被分解成一个独立的库，你有几个选项，我将在下面描述。
但无论哪种情况，这都需要纪律，而且可能会变得非常混乱和容易出错。这是因为您所做的任何将属于master(公共基础(的更改与只属于P或Q的更改混合的提交都必须手动分离并合并到master。
(A(master、P和Q分支(如您所知(
- 您将维护具有分支结构的单个回购，如上文所示
- 就提交而言，最简单的做法是在工作时戴上三顶不同的帽子：；公共基础的显影剂"P〃的显影剂；以及"；Q的开发者；。虽然这对于管理提交和分支来说更简单，但对于开发来说可能更困难，因为这会阻止您以集成的方式在
P或Q中开发公共代码，然后将公共部分移动到master中。- 为您戴的任何帽子签出分支，进行您想要进行的更改，并将其提交给该分支
- 更改公共基础
master后，将P和git merge中master上的最新代码签入P。对Q执行相同操作 - 如果您在戴帽子时犯了错误，并做出了
P或Q分支中常见的更改，请参阅#3
- 如果独立于
P或Q在心理或身体上开发公共基础太难了，如果你需要以集成的方式进行开发，那么当你需要从P或Q中分离出公共部分时，你将付出代价。假设您在P上做了很多更改，并使其按您的意愿工作。现在，您必须先签出master，然后签出git merge --no-commit P或git cherry-pick --no-commit <specific P commits>，然后在提交到master并将这些更改合并到Q之前，剔除P特定的更改
(B(master、P和Qrepos(forks(
此选项与(A(基本相同，只是您维护的不是分支机构而是单独的回购。您将从公共基础repo开始，然后将其分为P和Qrepo两次。您可以将P和Q配置为具有与upstream回购相同的公共基础回购。
如果将upstream设置为指向基本回购的本地副本，则可以使用git fetch、git pull和git push命令将提交从一个回购复制/合并到另一个回购。
如果将upstream设置为指向基础repo的GitHub副本，则可以使用GitHub的拉请求机制将您在P或Q中所做的更改推送到upstream。
上面#2和#3之间的区别也适用于这种情况。
(C( 库中的公共基础
如果你能使用的话，这是最好的方法。共享库p和Q将在单独的repo中开发。
您可以使用多种方法之一将公共库集成到p和Q中。Package Manager与Git Submodule/Subtree描述了使用Git实现这一点的最常见方法：git submodule、git subtree或您正在编码的语言的包管理器。
一旦你选择了，在Web或StackOverflow上就有大量的资源可以用于这些选择，将子模块与子树进行比较，以及如何在"；单回购；如果这是你想做的。