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

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.