2

我对此进行了很多搜索，如果这是一个骗局，我深表歉意，我找不到任何直接解决我问题的答案。

我们有一个客户会考虑一个功能一段时间，在这样做的时候会很快批准另一个功能。

这意味着我们从 master 创建功能分支并将它们合并到部署到 QA 环境中，这一切都很好，但是当 feature2 在 feature1 之前获得批准时，我们需要将 feature2 合并到我们的发布分支中，而没有任何 feature1 的痕迹。

这听起来不错，但这已经持续了一段时间，并且 master 和 release 之间的提交历史不断不同。

我们尝试过的；

  1. 从 master 分支 feature2 并将 feature2 分支合并到版本中 - 这会导致太多不需要的提交历史记录。
  2. 将 master 合并到版本中。见问题 1。太多的历史。
  3. 从版本中创建功能分支，而不是 master。理论上很好，但经常发生太多冲突，使其成为一个不错的选择。
  4. 采摘樱桃。呃。这是我们唯一能够做的事情，它促成了我们分歧的分支。

有人对此有建议的工作流程吗？

我认为我们可以在发布分支的位置从 master 分支，但我认为我们会遇到与上面 2 相同的问题。

编辑

请参阅下面的链接二（什么样的 Git 工作流程适合我们的情况？） - 可能一个“临时”分支可以用于部署到开发环境？

一些类似的讨论；
哪些 git 分支模型实际上有效？
什么样的 Git 工作流程适合我们的情况？

4

1 回答 1

1

试试git merge --squash branchname （文档）。

它将整个分支变成一个提交，从而消除了历史问题。这使您可以遵循一种模式，在这种模式下，您有一个持久的主分支和发布分支，以及彼此一无所知的瞬态特性分支。master 是功能的分支和合并的地方，release 分支是在考虑发布时合并 master 的地方，而功能分支是大部分开发发生的地方。当一个特性被批准时，它会被合并到 master 中git merge --squash，这导致 master 对整个功能有一个提交。然后可以根据需要删除功能分支。此外，如果该功能没有被删除，它似乎会继续愉快地与 master 来回合并，因此您甚至可以保持分支并单独处理该功能，定期使用git merge --squash将其合并到 master，并git merge合并掌握它（保持最新）。

如果更多的历史记录很重要，那么您可能会查看git rebase -i，您将在其中将功能分支合并到 master 中，然后使用 清理生成的历史记录git rebase -i。按这个顺序做意味着特性分支仍然和其他地方一样，而主分支有一些额外的提交，代表特性分支上的开发。问这听起来是否有趣，我会尝试进一步解释。

对于发布，您可以使用git merge --squash合并到发布分支中，这将使其更加干净，或者您可以将 master 的（现在有限的）历史记录拉入发布git merge

以下是 git log 可能显示为结果提交图的内容：

* d779567       master Done
* 298c1c7       master Closer
* 736d826       master Building
| * 4657b01     fdab66dc33 Done!
| * 3af011a     fdab66dc33 Closer...
| * 6372833     fdab66dc33 Closer...
| * d345a43     fdab66dc33 Building...
| * 0b64509     fdab66dc33 Building...
| * 9da143c     fdab66dc33 Building...
| * c99dbce     fdab66dc33 Building...
| * 501a25c     fdab66dc33 Building...
| * 4f999ee     fdab66dc33 Building new feature
|/  
* e891881       master Work on master
| *   3571493   release Releasing version 2!
| |\  
| |/  
|/|   
* | 68f75f0     master Feature 1 done
* | 5dbe17c     master Feature 2 done
| * bbcc8e8     release Bugfix on current release
|/  
* d5732fd       release Work directly on master
* 1098d81       release Initial commit

从底层开始工作：一些初步工作已经完成；发布了一个版本，然后我们意识到我们需要修复其中的一个错误；我们从一开始就以相反的顺序获得了两个功能的批准，另一个版本被删掉了。然后一些工作直接发生在主人身上。现在事情变得更加混乱了。右边的分支（fdab66dc33 实际上是分支名称）是一个特性分支，已经对其进行了很多提交。左边的分支是 master 分支，顶部的三个 commit 是把 feature 分支合并到里面，然后用git rebase -isquish 把 feature 分支的一些 commit 压在一起的结果。

于 2013-05-30T10:23:33.723 回答