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

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

含义：当您和您的同事都在您自己的功能分支（A，B，C和主人）上工作时，您应该将您的临时服务器设置为仅从staging分支拉出来

每当更改必须生效时，您只需将该功能合并到staging分支并将其推送到服务器 - 然后暂存环境将拉动该分支并进行部署。

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

一旦投入生产，您可以删除功能分支并重新开始..

<强> TLDR：将您的每个环境视为一个分支，只有在功能必须到达时才会被推送到该分支。这样，您甚至可以从不应该去那里的分支/环境中恢复更改。

我会采用看板方式 - 更容易，而且你似乎做得更好。

Answer 2

我们已经将git flow用于这样的场景。

由于git flow允许您创建多个功能并且只将您想要的功能推送到开发和主分支，因此它应该很好地满足您的要求。

以下是git-flow的一些链接：

https://github.com/nvie/gitflow/ http://yakiloo.com/getting-started-git-flow/

Answer 3

我已经改编了git-flow：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

最大的区别在于你从sprint / itteration的同一个开始启动所有功能。

Answer 4

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

One Master远程存储库。
分期时的一个本地分支。
一个当地的生产分支。

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.

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

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

在我们的情况下，这是最好的，希望它有助于某人。

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

4 个答案: