git多项目合并

Question

我们将一个项目分配到自己的代码库中，但它将紧跟其分支的项目。

我认为它的工作原理如下：

分叉项目将对品牌产品进行一些初步更改。我不想与原始项目共享这些更改，但是我希望合并更改。

我们设置它的方式是单独的repos，它们现在具有相同的历史记录，只是为彼此添加遥控器。

我想到的工作流程是：

我们应该尝试使用功能分支，每次只提交1次 功能，所以我们每个人都可以选择樱桃挑选。无论何时你 处理一个功能并进行提交，只需执行git commit --amend即可 该功能的分支。当它最终确定时，我可以挑选它 提交。

我不喜欢这样，因为如果在挑选樱桃之后功能发生了变化，开发人员需要记住不会结束但是会创建一个新的提交。

我希望通过合并或改造来做到这一点。

Answer 1

构建此方法的一种可能方法是使用三个存储库，其中一个存储库是“白色标签版本”，另外两个存储库用于两个前端。两个前端将“白色标签版本”存储库作为子模块引用。

使用这种结构你：

1. 明确地将白色标签版本称为“受控”但其他人
的共享资源
2. 但仍允许通过两个前端更改白标版本
3. 允许两个前端独立开发其存储库内容。

如果你的两个前端相似，那么它们可以是一个存储库的分支（但都取决于子模块）。在这种情况下，如果您在两个前端之间来回合并，一个好方法是为每个功能创建一个分支。每个功能都有一个分支，使您免于“每个分支一次提交”的限制。 [编辑]根据功能分支的性质，您可以a）使用<branch-base>..<branch-head>挑选所有提交;或者b）将分支上的所有内容重新绑定到一个提交中，然后挑选一个提交或c）使用merge / rebase将功能分支转移到另一个分支上（参见git rebase文档中的大量示例，尤其是--onto选项。）[/ edit]

同样here是一个常见的，备受推崇的分支模型，讨论了特征分支。

[edit2]如果您愿意，可以使用一个存储库执行此操作。保留三个主要分支：white-label-dev，prod1-dev，prod2-dev，让三个团队中的每个团队的开发人员只在他们的分支机构或其分支机构创建的分支机构上运行。当一个团队有一些应该共享的东西时，“企业集成主管”将完成从一个团队的工作转移到其他团队的分支的工作。 （如上所述移动提交。）

你的团队需要一些纪律来避免与其他团队的分支混在一起。但是，如果你有一个共享存储库，你可以分配钩子以防止从错误的团队推送到另一个团队的分支机构。 [/ EDIT2]

Answer 2

建议的工作流程：

• 每个功能的新分支
• 开发人员正常提交到功能分支
• 合并到主分支时：

git merge --squash -m 'new feature' branchname

现在，删除分支！

git branch -D branchname

• 如果开发人员需要修改某些内容或更改功能，他会从主人创建一个新分支。其他一切都是一样的。

下一个合并将在主分支上显示为不同的提交。

Answer 3

我认为您希望遵循Github用于保持分叉项目更新的类似过程。

首先是whitelabel回购。这是其他项目将从中分叉的那个。然后其他项目将是whitelabel的克隆，whitelabel被设置为upstream个回购。使用此功能，您可以执行git merge upstream/master或git 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

Answer 4

如果fork应该遵循forkee的脚步，最好将fork保存在master存储库的分支中。否则，挑选上游的变化，这将变得不必要的困难。

考虑分叉存储库的好处/成本。保持一致意味着拖延差异（可能很小？）。

使用gitolite，您可以根据需要控制对分支的访问。

Answer 5

假设您的品牌代码都可以“干净地”驻留在 views / 目录中  我建议将 views 分解为自己的git repo并将其嵌入到你的内容中 主要项目。见here

然后您可以选择

1. 在您的分区的单个视图回购中使用git分支，或
2. 为每个品牌使用单独的观看回购。

我更喜欢1.因为我预计部分视图可能需要通过将它们折叠回白色标签来共享，或者从白色标签中挑选它们< / em>加入品牌。

---

可能的项目工作布局

白标项目布局;

- 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"

Brand [n]项目布局;

- app_brand2/      <<-- clone of "app" repo on default branch
  + config/
  + controllers/
  + errors/
  + views/         <<-- nested clone of "views" repo on branch "brand[n]"

---

赞成

• 您无需挑选以保持共享代码库的最新状态 - 只需拉动。
• “app”的拉动不会影响“观看次数”。
• 强迫你保持干净的mvc模型 - 不是坏事:)。

缺点

• 您/其他人需要了解更复杂的项目布局。
• 强迫你保持干净的mvc模型 - 并不总是一件容易的事情：）

Answer 6

假设您可以控制两个存储库，解决方案很简单。

维护每个功能的分支。

维护功能发布分支。

功能完成后，将功能分支合并到发布分支并标记它。

如果该功能需要修复错误，请在功能分支中修复它，然后使用新版本重新合并并重新标记它。

您可以在功能发布分支中集中选择更新的功能或错误修复。您可以轻松识别标签所具有的功能版本。

您还可以轻松查看功能发布分支上的提交历史记录，以查看是否有任何更新。

除了这些分支，我还维护一个版本发布分支。公开发布的任何内容都是QAd，然后提交给版本发布分支。

每个人的本地工作存储库可以根据需要或需要提供尽可能多的提交而不受限制。

主存储库已经明确划分了分支，并且明确分段提交，不断合并到功能发布和版本发布中。

通过功能发布分支或版本发布分支，可以轻松更新任何分支。他们想要的任何时候，分叉的回购可以抓住合适的东西。

黄色分支是标记的功能发布分支，绿色是版本发布分支。福克斯可以从任何一个分支中自由地拉出来，并确切地知道他们用樱桃采摘得到了什么。工作特征分支都基于发布分支，除非它们是相互依赖的。错误修复与发布分开处理。

就像我说的那样......所有开发人员都有自己的工作回购，可以自由地承诺这些。