Git working strategy - many features, very frequent releases

Question

here's the description of my everyday work:

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.

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.

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.

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

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.

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?).

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.

Thanks.

Answer 1

From what you've described I would adopt a strategy of a release branch and many working branches.

Meaning: You should set up your staging server to only pull from the staging branch while you and your co-workers are all working on your own feature branches (A,B,C and maybe master)

Whenever a change has to go live you simply merge the feature into the staging branch and push it to the server - the staging env then pulls that branch and deploys.

Once you've got approval from your client you can then push the feature branch (that was already merged into staging into another branch (maybe stable) and then deploy that to production.

Once in production you can delete the feature branch and start over..

TLDR: Treat each of your environments as a branch that only gets pushed to when a feature has to go there. That way you can even revert changes from branches/environments that are not supposed to go there.

And I'd go with a Kanban approach - easier and for what you seem to be doing better suited.

Answer 2

I finally chose the following way of handling this:

• One Master remote repository.

• One local branch on staging.

• One local branch on production.

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

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.

The same goes for programmer B working on feature B.

Going live on production:

#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.