这是我日常工作的描述:
两名开发人员从事许多小功能或修复工作，假设每位开发人员每天 3-4 次。 我需要能够同时处理功能 A - B - C，而我的同事处理功能 D 和 E。
星期一: 功能 A 被推送到登台服务器以供客户审查。 功能 B 被推送到同一登台服务器以供客户审核。 功能 D 被推送到同一登台服务器以供客户审核。
星期二: 我们收到客户对 A 和 D 的批准(但不是 B)。他们需要立即接受这些更改。
星期三: 功能 C 被推送到同一登台服务器以供客户审核。 最终获得了 B 的批准。
星期四: 功能 B 必须立即投入生产。
星期五: 在上一个生产版本中发现错误，我们需要回滚到以前的版本。
这不能被视为类似 Scrum 的过程，因为没有机会将功能分组到故事或冲刺计划中。这更像是一个维护过程(也许是看板？)。
您能举例说明如何使用 Git 处理这个问题吗？假设现在，我们只有一个主分支，每当我们想将任何东西推送到暂存或生产环境时，我们必须“git pull”使所有更改生效(即使是不需要的)。 git“cherry-pick”如何检索特定的提交？每个特征一个分支似乎太繁重了，因为我们有太多的特征。如果你能给出 Git 命令和分支的具体例子(只是为了展示主要思想，不需要 100% 正确)那就太好了。
谢谢。
最佳答案
根据您的描述，我会采用发布分支和许多工作分支的策略。
意思:当你和你的同事都在你自己的功能分支上工作时(A、B、C，也许还有 master)，你应该设置你的登台服务器只从 staging 分支 pull )
每当更改必须上线时，您只需将该功能 merge 到 staging 分支并将其推送到服务器 - staging 环境然后 pull 该分支并部署。
一旦您获得客户的批准，您就可以将功能分支(已经 merge 到 staging 中)推送到另一个分支(可能是 stable)，然后部署用于生产。
在生产环境中，您可以删除功能分支并重新开始。
TLDR: 将您的每个环境都视为一个分支，只有在必须将某个功能放到那里时才会被推送到那里。这样你甚至可以从不应该去那里的分支/环境中恢复更改。
我会选择看板方法 - 更简单，而且看起来更适合您的工作。
关于Git 工作攻略——功能多，发布非常频繁，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8537723/