Git工作策略 - 许多功能,非常频繁的发布

Question

这是我日常工作的描述:

两位开发人员在许多小功能或修复程序中工作,假设每个开发人员每天工作3-4次.我需要能够同时处理功能A - B - C,而我的同事则在功能D和E上工作.

星期一:功能A被推送到临时服务器以供客户审阅.功能B被推送到同一个登台服务器以供客户审阅.功能D被推送到同一个登台服务器以供客户审阅.

星期二:我们收到客户对A和D的批准(但不是B).他们需要立即接受这些变化.

星期三:功能C被推送到同一个登台服务器以供客户审查.最终收到B的批准.

星期四:功能B必须立即推向生产.

星期五:在上一个生产版本中发现了一个错误,我们需要回滚到以前的版本.

这不能被视为类似Scrum的过程,因为没有机会将功能分组到Stories或sprint规划中.这更像是一个维护过程(可能是看板？).

你能举例说明如何使用Git处理这个问题吗？假设现在,我们只有一个主分支,每当我们想要将任何东西推送到分段或生产时,我们必须"git pull"使所有更改生效(即使是不需要的更改).那些用于检索特定提交的git"cherry-pick"怎么样？每个功能的一个分支似乎太繁重,因为我们有太多的功能.如果您能给出Git命令和分支的具体示例(仅显示主要想法,不需要100%正确),这将是很好的.

谢谢.

Answer 1

根据您的描述，我将采用发布分支和许多工作分支的策略。

含义：您应该将登台服务器设置为仅staging在您和您的同事都在自己的功能分支（A，B，C甚至是主节点）上工作时才从分支中拉出

每当需要进行更改时，您只需将功能合并到staging分支中，然后将其推送到服务器-临时环境会拉出该分支并进行部署。

获得客户的批准后，就可以推送功能分支（该分支已经合并staging到另一个分支（也许是stable）中），然后将其部署到生产中。

投入生产后，您可以删除功能分支并重新开始。

TLDR： 将您的每个环境都视为一个分支，仅在功能必须进入该分支时才被推送到该分支。这样，您甚至可以从不应该去的分支/环境中还原更改。

我会采用看板方法-更简单，并且您似乎更适合自己。

Answer 2

我最终选择了以下处理方式：

• 一个主远程存储库。

• 当地一家分支机构正在筹建中。

• 一个当地分支机构正在生产。

  git checkout -b staging #on staging server
git checkout -b production #on production server

程序员 A 需要开发功能/补丁 A：

#local development box
git checkout master
git checkout -b issue-A
#work on the feature
git push origin issue-A
#log in to the staging server
git checkout staging
git pull origin issue-A #merge with the staging branch, changes are live on staging.

对于开发功能 B 的程序员 B 来说也是如此。

投入生产：

#log in to the production server.
git checkout production
git pull origin issue-A #merge with the production local branch, changes are live on production.

此外，当更改生效并获得批准时，可以将本地生产分支推送到 master：

git add <files>
git commit <commit info>
git push origin master

这是在我们的情况下最有效的方法，希望对某人有所帮助。