Recommended git workflow for test and production instances

Question

Although I've been using git for some time now, I still consider myself a n00b, so please don't be too harsh on me.

I'm maintaining a "corporate" mainframe system as two non-identical copies. Let's call them Test and Production. The mainframe has nothing that I (or, probably, any of you) would consider to be a version control system, so I'm using git on the desktop to provide me with version control. Here are the main features of my current workflow:

• The desktop and mainframe are "synced" with FTP. In the end, all development work, whether written on the mainframe or the PC, ends up on the PC in a git branch.

• I have no access to any kind of "modern" deployment technology such as Hudson

• I have two main branches, called Test and Prod. Because of the (inherited) structure of the product, there a number of differences in the code between the Test and Prod instances. For example, all the display panels need clearly to identify whether this is Test or Prod, but there is no way to configure this at a single point.

• I generally create other branches ad-hoc for specific development subprojects.

• General development is done on the Test branch, with multiple commits. When ready, these are cherry-picked onto Prod, tagged with a change number, and uploaded when approved.

• Emergency work, fortunately rare, is done on the Prod branch and cherry-picked onto Test.

• The cherry-picking, very occasionally, requires a manual merge.

I should like to improve this workflow. Currently my repository is full of parallel identical changes on the two branches.

I think I would prefer to do it this way (for Test -> Prod):

• Once development is ready, create a new branch at the HEAD of Prod

• Collapse this set of development changes into a single change on the new branch

• Merge this new branch on to Prod. Bear in mind that their common ancestor is before the changes that make Test different from Prod

It appears that git rebase -i might do the job, but I must confess that git rebase is my pons asinorum, and somehow I've managed to mess up my tree a number of times.

So my questions are these:

1. Please suggest a better way, within the constraints of the product.

2. If my preferred approach is viable, could someone please suggest the correct parameters for git rebase -i?

Answer 1

Regarding differences between Test and Prod, check if you can detect if you are in one environment or another.

That would allow, for files with a platform-specific content, to be modified on checkout with a filter driver through a smudge script.

That way, you wouldn't have to maintain branches just to separate to nearly identical sets of code.