如何合并仅包含在git分支中的提交

Question

我们目前正在从svn迁移到git，我们在svn中使用基于trunk的工作流程。

我们有两个git分支，主开发和发布。开发和发布是主分支。我们不想从开发中创建一个功能分支，并且在我们完成合并之后，通过拉取请求进行开发。 QA在开发分支上进行所有测试。 QA批准后，我们​​不想将功能分支合并到发布分支中。现在这里的问题是，如果有10个以前的特性合并到开发之前，我们创建了这个特性分支，那么所有这10个特性的提交也将包含在合并请求中。

我们想知道的是如何将FEATURE BRANCH中的提交合并到发布分支中。

我们研究了在sprint结束时创建发布分支的git流，但问题在于它将包含合并开发的所有功能。在我们的系统中，我们对开发分支进行QA测试，而不是单个功能分支进行QA测试，在git流程中，您应该先单独测试每个功能分支，以避免过早集成并减少回退。我们可能可以使用它，但问题是我们无法为我们的所有功能设置服务器的资源进行测试（服务器/每个功能的部署）

关于我们现在正在发生的事情的基本概念svn现有工作流程

我们有两个分支，干线和分段。我们开始我们的主干工作，在完成我们的功能后，我们将工作交给主干。后缀我们得到一个释放完成的干线分支到质量保证环境。质量保证测试的功能，在我们从质量保证中得到确认后，我们将我们的功能合并到暂存分支中。为此，我们从trunk中选择所需的修订版本，并将它们合并到分段分支中。 QA然后进行另一个最终的回归测试。在我们的冲刺结束时，我们从分期到生产和演示环境进行构建。

有谁知道我们如何使用两个分支开发和发布，并从开发创建功能分支，只将功能分支更改合并到发布分支。这是因为我们每个分支只能有两个测试环境。请注意，这个应用程序没有任何单元测试。

亚历山大Polomodov

编辑更新1

感谢您的见解。由于评论大小不够，我将其添加到主帖子中。具有讽刺意味的是，这是我们最初尝试的，但没有找到它来满足我们的需求。主要原因是每当我们创建一个功能分支时，如果发生冲突，只有在试图合并到开发分支时才会检测到。这是因为我们在没有其他人的变化的情况下开始我们的本地发展。现在让我们假设我解决了合并冲突，现在让我们来说说特征分支本身（我有一个问题，我在哪里修复它，稍后再介绍）。然后在QA通过并给我OK后，我将我的分支合并到版本中。 但是现在我得到另一个冲突，为什么？由于我简单地解决了合并冲突以匹配开发分支，现在导致此冲突的其他人的代码不能正常运行。如果我们要开发一个功能分支，并且当我们从开发中提交一个合并请求来释放IF时，分支中的提交只能以某种方式进行，那么剩下的唯一问题就是修复发布分支上的任何合并冲突ONCE。而且，由于我们创建了功能分支，所以每个人都将与其他人的代码一起工作。

编辑更新2

我试了第二种方法，但不能使它工作，在理论上这是我想做的事。我创建了一些我使用的示例步骤。

#create the repository  
git init 

#create the initial java source 
mkdir src 
gedit src/Test.java 

#add and commit the code to the repository in master 
git add src 
git commit 

#create the release branch from master 
git checkout -b release 

#create the develop branch from master 
git checkout master 
git checkout -b develop 

#create the feature1 branch from develop 
git checkout -b feature1 
gedit src/Test.java #add another method 
git add src/ 
git commit 

#merge the feature1 to develop 
git checkout develop 
git merge feature1 

#create the feature2 branch from develop after the merge 
git checkout -b feature2 
gedit src/Test.java #add another method 
git add src/ 
git commit 

#merge the feature2 to develop 
git checkout develop 
git merge feature2 

#create a branch for rebasing the feature2 
git checkout feature2 
git checkout -b feature2release 
git rebase release 

在上面我创建一个主和两个分支开发和释放它。之后，我开始创建功能分支，并将其开发并提交给它们，并将它们合并到开发中。每个功能只是将新的java方法添加到代码中。现在我只想合并功能2中引入的方法来释放，而忽略任何其他提交的提交（在这种情况下只是由功能1引入的方法）。现在要做到这一点，我创建了一个feature2release分支，然后通过发布来重新分配。但是，当我这样做时，我收到以下消息。

Current branch feature2release is up to date. 

你能告诉我我做错了什么，或者我应该怎么做。

Answer 1

如果我理解你的问题，我可以提出一个解决方案。但在此之前我说一下我对你的问题的认识几个字：

• 你develop分支是相当不稳定，并在此分支
• 你release分支是相当稳定的质量保证运行测试，并且将它部署到您的生产等高
• 您需要创建功能分支（即feature1，feature2，feature3），但它合并develop分行QA检验
• 您需要包括只有一些特性分支（不是所有的合并开发）为您[R下一个版本

如果这一切都真实的，你可以：

• 创建一个从稳定release分支
• 合并的每个特性分支（feature1，feature2，feature3）各准备功能分支develop用于测试
• 如果此功能分支失败，则所有修复都应在其分支中完成，而不是develop分支
• 当功能就绪，其分支机构也准备合并发布
• 在下一版本的时候，你只选择所需的分支，并合并其释放

有这种方法的一些显著的缺点，但这些缺点与不同特征分支中开发的功能交集有关。在开发分支上进行的qa测试很容易在false positives and false negatives errors找到bug。

我已经添加了一些解释图纸：

另一个工作流的问题编辑的零件

• 创建一个从不稳定develop分支改变每个特征分支（feature1，feature2，feature3）其他人的
• 合并每个准备功能分支develop为TES TS
• 如果此功能分支失败的所有修复应在其分支机构完成，而不是develop分支

• 当功能就绪，其分支机构也已准备好创建分支优点1，用于释放用于合并与此释放步骤

  git branch feature1-for-release feature1 # create branch for release git chekcout feature1-for-release # checkout to this branch git rebase release # rebase from master

• 在下一版本的时候，你只选择所需的分支（即特征1换释放）和合并其释放

这种方法有一些显着的缺点，首先你永远不会在这个特定的重新设计的分支上运行测试。这是一个问题。我可以举一个简单的例子：

• 您从合并后的分支feature0开发一些功能
• 您可以使用此功能从feature0启动分支feature1并创造出一些新的特点
• 你feature1已通过QA -tests与您共创feature1-for-release分支
• 假设你决定加入到下一个版本feature1-for-release分支而不是feature0-for-release分支
• 您release将与非工作的功能从feature1任务进行部署，因为它取决于feature0这是此版本

更新另一个工作流的问题编辑的部分

我遵循的步骤缺席编辑更新2并获得相同的结果。 Test.java在主设备具有一个行：

// initial 

Test.java在特征1有两条线：

// initial 
// feature1 

Test.java在特征2具有3行：

// initial 
// feature1 
// feature2 

而它终止了这种方案的使用。现在我想我可以解释为什么：

• 底垫是一种方法适用于从另一个分支的变化顶端的差异
• 所以在release分支没有变化，你会得到feature2release is up to date
• 它我的错，我很少用复杂rebase（通常只用于壁球承诺，并在消息提交的变化），所以我忘了这个在我的逻辑结构的替代方案

我也尝试创建特点2 releaseV2分支使用Git的组合应用+ git的差异在为：

• 从版本创建分支feature2releaseV2
• 起点和终点之间的应用创造特点2

• 的差异，但我得到这个错误：

  # b1d49dd - end of feature2, #78d0839 - start of feature2 $ git diff b1d49dd 78d0839 | git apply -v Checking patch src/Test.java... error: while searching for: // initial // feature1 // feature2

我也尝试使用挑肥拣瘦创建feature2releaseV3分支，但得到这是非常难的冲突解决：

$ git status 
On branch feature2releaseV2 
You are currently cherry-picking commit b1d49dd. 
    (fix conflicts and run "git cherry-pick --continue") 
    (use "git cherry-pick --abort" to cancel the cherry-pick operation) 

Unmerged paths: 
    (use "git add <file>..." to mark resolution) 

    both modified: src/Test.java 

$ git diff 
diff --cc src/Test.java 
index 348ec50,9a56d40..0000000 
--- a/src/Test.java 
+++ b/src/Test.java 
@@@ -1,1 -1,3 +1,7 @@@ 
- // initial 
++<<<<<<< HEAD 
++// initial 
++======= 
+ // initial 
+ // feature1 
-// feature2 
++// feature2 
++>>>>>>> b1d49dd... feature2 

其结果是，我有一个忠告：

这是必然更加频繁地创建发布和在这种情况下，每个开发人员都可以开始在新的特性分支稳定版本。例如，我们每天部署我们的系统一次或两次，并从发布版本启动我们的功能分支。