Git工作策略-许多功能，非常频繁的发布 [英] Git working strategy - many features, very frequent releases

问题描述

这是我日常工作的描述:

here's the description of my everyday work:

两名开发人员，他们从事许多小的功能或修正，例如，每个开发人员每天需要3-4. 我需要同时处理A-B-C功能，而我的同事同时处理D和E功能.

Two developers working in many small features or fixes, let's say 3-4 per day for each developer. I need to be able to work on features A - B - C at the same time, while my coworker works on feature D and E.

星期一: 功能A被推送到登台服务器以供客户端检查. 功能B被推送到同一登台服务器以供客户端检查. 功能D被推送到同一登台服务器以供客户端查看.

Monday: Feature A is pushed to a staging server for client review. Feature B is pushed to the same staging server for client review. Feature D is pushed to the same staging server for client review.

星期二: 我们从客户那里获得了A和D的批准(但没有获得B的批准).他们需要立即进行这些更改.

Tuesday: We receive approval from the client for A and D (but not for B). And they need to go live with those changes immediately.

星期三: 功能C推送到同一登台服务器以供客户端检查. 终于收到了B的批准.

Wednesday: Feature C is pushed to the same staging server for client review. Approval for B is finally received.

星期四: 功能B必须立即投入生产.

Thursday: Feature B has to be pushed to production immediately.

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

Friday: An error is discovered in the last production release and we need to roll back to the previous version.

不能将其视为类似于Scrum的过程，因为没有机会将功能分组到Stories或sprint计划中.这更像是一个维护过程(也许是看板?).

This can't be treated as a Scrum-like process because there's no chance of grouping features into Stories or sprint planning. This is more like a maintenance process (maybe Kanban?).

您能举个例子，说明如何使用Git处理该问题吗?假设现在，我们只有一个master分支，并且每当要将任何东西推送到暂存或生产中时，我们都必须"git pull"使所有更改生效(甚至不需要的更改). git"cherry-pick"来检索特定的提交呢?每个功能一个分支似乎太繁重，因为我们有太多功能.如果您可以给出Git命令和分支的具体示例(仅是为了展示主要思想，不需要100％正确)，那就太好了.

Can you give an example of how you would handle this using Git? Assume that right now, we have only one master branch and whenever we want to push anything to staging or production, we have to "git pull" making all changes live (even the unwanted ones). What about git "cherry-pick" to retrieve specific commits? One branch per feature seems too onerous as we have too many features. If you could give specific examples of Git commands and branches (only to show the main idea, don't need to be 100% correct) that would be great.

谢谢.

推荐答案

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

I finally chose the following way of handling this:

• 一个主远程存储库.

• One Master remote repository.

一个临时分支.

一个本地生产分支.

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

程序员A需要处理功能/补丁A:

Programmer A needs to work on a feature/patch 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也是如此.

The same goes for programmer B working on feature 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.

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

Also, local production branch can be pushed to master when changes are live and approved:

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

这是在我们的情况下效果最好的方法，希望对您有所帮助.

This is what worked the best in our situation, hope it helps someone.

这篇关于Git工作策略-许多功能，非常频繁的发布的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！