我们目前正以非常标准的方式使用Gitflow来支持每周冲刺。
为了缓解压力，我们即将采取稍微不同的发布时间表，这将涉及每周一次的小改变。冲刺，以及双周的功能变化＆＃39; sprint，都在同一个网站/ git repo。
要做到这一点，我需要找到一种方法，能够完成每两周一次的功能变化冲刺的功能，而不会将它们包含在每周的小变化冲刺版本中。
有没有办法让两个发展分支......一个小的变化＆＃39;发展分支，以及“功能变革”。开发分支，然后在每个分支中创建功能？
由于
答案 0 :(得分：0)
我们是在谈论GitFlow分支模型，还是某些团队用来自动化该模型所要求的分支/合并任务的git扩展？
如果您只是使用分支模型，那么您当然可以以适合您团队的方式改变它。我可以想到几种方法来完成你描述的内容，尽管它们都有潜在的缺点;你只需要决定什么对你的团队有用。
如果你正在使用git扩展，那么我想不出任何方法让它们直接支持你想要的东西;所以关键是要以尽可能多地保留扩展功能的方式修改分支工作流程。 （或者，这些工具是开源的......我想你可以修改它们。或者只是将扩展放在一边;我从来没有真正理解它们提供那么多的价值，当然我很难忘记一些东西。）
通常，您应该警惕在模型中添加新的长期分支，因为它为事物提供了不同步的机会。在您的情况下，您可以在最糟糕的情况下每隔一到两周同步一次。我认为理论上“小变化”分支不应该做任何如此彻底的事情，以至于它可能会造成困难的合并冲突......但是，你知道理论和实践之间的区别吗？ [1]
从master分支的角度来看，我倾向于让事情看起来尽可能“正常”。这意味着develop应该是所有发布分支的来源，develop上的所有内容都应该为下一个版本做好准备;这反过来意味着develop是“小变化”特征的直接分支和合并点。
然后你可以将每个“功能变化”冲刺视为一个功能本身。因此，在“功能变化冲刺N”的开头，您将从develop创建一个分支 - 比方说fchangeN。功能更改冲刺的功能将从fchangeN分支并合并回fchangeN，并且在两周结束时develop将合并到master（并且可能已删除）。
您必须提出的一个问题：如果应用修补程序并将其合并到develop和fchangeN，是否还要将其合并到活动fchangeN分支？通常，您不会考虑将修补程序直接合并到功能分支，这或多或少是我们尝试处理fchangeN的方式;但它确实是一个更大的变化积累，因此可能值得思考一个修补程序是否可能影响这两周的代码。
我想您可以同样问自己是否应该将小变更功能合并到develop - 或者，如果不是，可以在中间冲刺点将fchangeN合并到fchangeN （你从一个小变化冲刺切换到下一个冲刺）。我希望小的变化， small ，对于冲刺工作来说不那么重要;但同样，你的团队必须决定是否值得为你的团队做额外的工作。
上述内容的一种变体：您可能会注意到在创建fchange(N+1)时删除了fchange;所以你可以保留一个分支develop。然后，诀窍是确保每两周后将“双向”与git checkout develop
git merge --no-ff fchange
git checkout fchange
git checkout --ff-only develop
合并。
fchangeN无论是哪种变体，一个更有趣的问题是：你如何处理在sprint结束时没有完成的“功能变化”功能？理论上，您可以保持功能分支打开/未合并。随着故事延续到后续sprint中，功能分支将合并回到后续sprint的instance.content_template_id = int(self.kwargs['pk'])分支。
这是“这种”做法吗？没有。没有任何一种方法，因为您正在尝试自定义工作流程以满足自定义要求。这是一种方式，可能有一些缺点，可能适合您的团队，也可能不适合您的团队。它的目标是尽可能保持“正常”，更喜欢“奇怪”的行为应该在最短暂的分支上，而最永久的分支应该正常行事。
[1] - 理论与实践的区别在于：理论上没有区别