免责声明：我不太了解合并或重新定位。我使用merge是因为它是git pull的默认效果。
我是一个软件工程师团队，经历了激烈的测试和截止日期以及不太激烈的实验和探索。以下是各阶段的简要概述：
阶段1（探索）：每个工程师在他自己的分支中工作，并在到达良好的停靠点时定期将他的分支合并到主分支中，例如，何时完成新功能。如果该功能无效，则会被删除（不会发生合并）。
阶段2（组合）：工程师在主分支中更紧密地工作，试图在截止日期前准备好产品。每周示威很常见。
第3阶段（恐慌）：截止日期前约2周通常非常激烈。短期黑客攻击是常见的，在此阶段所做的许多更改必须在截止日期之后恢复或重构。
阶段4（反映）：在截止日期之后进行验尸，并且在阶段3期间进行的更改要么被整合，要么被抛弃，要么被重构。
目前我们的团队严格使用合并而非变基。但是，在阶段4清理时，似乎在第3阶段使用变基可能是有益的。例如，我们无法在第4阶段执行交互式变基，因为当我们尝试这样做时，我们最终会被轰炸通过rebase过程进行合并冲突。我们通常最终使用git revert来“删除”第3阶段中不需要的提交。
我想到的是在第1阶段期间在不同的分支中工作，使用rebase将master拉入功能分支并合并以将功能拉入master。我不确定阶段2和阶段3的正确工作流程，但我最终希望能够在阶段4中运行交互式rebase，并且每次重播提交时都不会遇到合并冲突。
问题1：我的团队是否可以遵循第2阶段和第3阶段的工作流程，以便我们在阶段4中执行无缝的交互式变基，以便轻松删除和压缩旧的提交？
问题2：我是否更正在阶段1中使用单独的分支，我们将master重新绑定到功能分支上，并在功能开发完成时将功能分支合并为master？
答案 0 :(得分：0)
我们使用"forking" workflow，它与GitHub也是described at Atlassian's site。 Atlassian链接还探讨了git工作流的其他3种主要风格。
我觉得分叉工作流程最好，并在我们的环境中将复杂性降至最低。我们使用“主”分支来处理生产和“开发”中的QA。我们使用GitHub PR（拉取请求）作为讨论建议更改的地方，并且我们将TeamCity（构建测试服务器）连接到PR系统。