Recommended git workflow for test and production instances

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 开发者_StackOverflowonto 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?

---

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.

---

My recommendation is to merge your development (Test) and production (Prod) branches into each other more frequently rather than cherry-picking changes across. In particular, as changes are made in Prod, merge them frequently (at least once a day) into Test. When changes in Test are ready, merge them into Prod.

That you are cherry-picking commits from Test into Prod upon approval also suggests that your commits are not well split and are instead a few commits with very large diffs each. This makes it difficult to use your history to debug issues and makes it nearly impossible to revert a single change (by reverting a single commit).

I think by changing these two things in your workflow the larger question of how to manage a development and a production branch will be more obvious.