我希望有人可以指出我的工作流程对我们的设置有意义，因为在线分析所有冲突的信息已证明有些无用。
过去几个月，我们一直在使用“GitFlow”工作流程的修改版本。这些是我们的永久分支机构：
如您所见，我们的工作流程与传统的GitFlow不同，我们除beta外还有develop分支。因此，我们通常必须在beta中包含单个要素（来自要素分支），而不必合并develop。这就是我们出现问题的地方。
当我们从develop创建功能分支时，会经常与develop同步。这意味着，当我们尝试将某个功能合并到beta时，它会在develop上发生大量不需要的提交。
我们能够找到的唯一“解决方案”是手动重新（或挑选）从功能分支到beta的更改。这非常违反直觉，我知道必须有更好的方法。
另一个问题是，当我们需要为整个项目创建一个修补程序（应用于所有分支）时，我们会从master创建它，如果没有develop，它将不会合并到library(mixtox)
via_data$Concentration <- c(0.1974457, 0.3980034, 0.7921297, 1.5754719,
3.1546263, 6.2702489, 12.6250182, 25.2772970,
25.1103882, 49.9450449, 74.6800090)
via_data$Viability <- c(100.611247, 94.621027, 96.210269, 87.530562,
80.562347, 62.224939, 39.119804,
30.806846, 30.684597, 22.860636, 2.567237)
via_tuneFit <- tuneFit(via_data$Concentration, via_data$Viability,
eq="Beckon")
Error in if (nrow(param) > highBar) param <- param[sample(nrow(param), :
argument is of length zero
via_curvFit <- curveFit(x=via_data$Concentration, rspn=via_data$Viability,
eq="Beckon", rtype = "continuous",
param = c(77, 26, 1, 1, -6))
Processing continuous quantal dose-response data
Error in solve.default(t(jac) %*% jac) :
system is computationally singular: reciprocal condition number = 2.79026e-31
疯狂的合并冲突。这也可以通过挑选樱桃来完成，但我们绝对需要使用GitHub桌面应用和网站100％完成我们的工作流程。我熟悉命令行，但我已经得到了明确的指示，我们不能依赖它。
我考虑过的一个选择是尝试以rebase为中心的工作流而不是基于合并的工作流，但这是有问题的，因为变基不像合并那么简单（我甚至认为不可能没有命令行）。
请帮忙!!必须有一个简单的方法来做到这一点，我们只是没有看到它。
答案 0 :(得分：0)
是的，您可以使用 TortoiseGit 作为GUI或其他，操作类似。
TortoiseGit - ＆gt;创建补丁序列 - ＆gt;为自 - >＆gt;选择feature为 Number Commits 选择1（如果您只想在bate分支上应用最新提交） - ＆gt;好的
- ＆GT; TortoiseGit - ＆gt;切换/结帐 - ＆gt; beta - ＆gt; ok
- ＆GT; TortoiseGit - ＆gt; apply patch serial - ＆gt;添加刚刚创建的补丁 - ＆gt;应用
现在只有功能分支的最新提交才会应用于beta分支。
答案 1 :(得分：-1)
您正在寻找＆＃34;每个功能分支＆＃34;作者：Adam Dymitruk http://dymitruk.com/blog/2012/02/05/branch-per-feature/。这正是你要求的。
它与GitFlow有着不同的转折;它使用3种主要类型的分支：master，功能分支和qa分支。后者就像你的beta分支。
master是您生产服务器上的版本。 所有其他分支都脱离了这个分支。
功能分支就是这样。它们总是从master分支出来（这是与GitFlow的主要区别）。
qa＆＃34; next＆＃34;将在生产服务器上发布的版本。
它使用重基础以及git的rerere缓存，这避免了一遍又一遍地进行冲突解决。
功能分支永远不会合并＆＃34;返回＆＃34;进入某种develop分支（没有）。相反，在您有一组准备好进行测试的功能分支的任何时候，都会从头开始重新创建qa，从master开始，并准备好＆＃34;准备好＆＃34;功能分支合并到它。没有分支从qa开始，你永远不会向qa提交任何内容。您也永远不会将功能中的更改重新合并到qa，您总是从头开始。
这听起来像是一场冲突噩梦，但实际上非常简单。由于rerere缓存，通常只需要＆＃34;必要＆＃34;发生冲突。发生过一次的所有冲突然后由git自动解决。当然，使用相对简单的shell脚本自动执行此操作。
作为一项具有巨大优势的副作用，在任何时候退出qa的功能都是微不足道的（只需重建qa，而忽略该功能）。
这意味着当我们尝试将某个功能合并到测试版时，它会包含大量在开发时发生的不需要的提交。
使用Dymitruk，beta（a.k.a。qa）从master开始，将准备好测试的所有功能合并到其中。
另一个问题是，当我们需要为整个项目创建一个修补程序（应用于所有分支）时，我们从master创建它，并且它不会合并到develop中而没有疯狂的合并冲突
使用Dymitruk，修补程序进入master（当然，因为master反映了生产服务器）。然后，所有功能分支都会根据新master进行重新设定，最后，qa从头开始创建，从新master开始。
重新定位几乎不像合并那么简单（我甚至认为没有命令行可以做到这一点）。
在这种情况下，Rebase实际上比合并更简单，因为rebasing将一个提交应用于另一个提交，因此适用于较小的工作单元。相反，合并包含在分支上发生的所有提交。这意味着只要rerere缓存进入游戏，git就能自行解决大多数冲突。
显然，如果有人决定将所有空格更改为所有代码文件中的选项卡，并开始将此类更改提交到master，那么您就会感到烦恼。但这完全没有区别于合并;问题恰好发生在不同的时间点。
由于您只修改了功能分支，因此当多个开发人员一次在特定功能分支上工作时，您才真正得到通常的rebase问题。您可以通过使功能分支足够小来避免这种情况。或者，您必须在开发人员之间进行通信。但最终，如果人们意识到他们正在做什么，那么分散的基础肯定是可能的。如果有疑问，可以使用重标记作为备份措施，以避免实际丢失任何内容;但过了一段时间你会发现它确实是一个无问题。
来自评论：
假设某人正在处理功能分支，他们需要来自另一个正在进行的功能的代码（这种情况经常发生）。
您可以从另一个功能分支而不是master启动功能分支。
当然，你必须要注意一点;如果父功能分支获得更多提交，则需要在其上重新绑定子项。如果master发生更改，则必须先确保先修改父功能，然后在父项上重新绑定子项，而不是master。
关于qa，没有任何变化。
由于您将使用脚本执行两项主要操作（重新构建qa，重新定义所有功能），因此只需在这些脚本中跟踪此操作（不需要任何其他操作）存储或配置;可以使用基本的git branch --list命令轻松扣除这些情况。
此外，有没有办法使用GUI完成此工作流程？
您至少需要（重新）创建qa并且已经编译了rebase脚本。由于在这些期间会有定期的冲突解决方案，因此需要开发人员注意，因此最好通过命令行脚本完成。当然，您可以使用常用的首选git GUI进行合并/ rebase冲突解决;在幕后，它像往常一样只是git。