推荐用于测试和生产实例的 git 工作流程
虽然我已经使用git有一段时间了，但我仍然认为自己是一个n00b，所以请不要对我太严厉。
我正在维护一个“公司”大型机系统作为两个不同的副本。我们称它们为测试和生产。大型机没有任何我（或者可能是你们中的任何人）认为是版本控制系统的东西，所以我在桌面上使用 git 来为我提供版本控制。以下是我当前工作流程的主要特点：
桌面和大型机通过 FTP“同步”。最后，所有的开发工作，无论是在大型机上还是在 PC 上编写，最终都在 PC 上的 git 分支中结束。
我无法访问任何类型的“现代”部署技术，例如 Hudson
我有两个主要分支，称为 Test和产品。由于产品的（继承）结构，测试实例和生产实例之间的代码存在许多差异。例如，所有显示面板都需要清楚地识别这是Test还是Prod，但是没有办法在单个点上配置它。
我通常会为特定的开发子项目临时创建其他分支。
一般开发在测试分支上完成，并进行多次提交。准备就绪后，这些内容将被精心挑选到 Prod 上，并标有变更编号，并在获得批准后上传。
紧急工作（幸运的是很少见）是在 Prod 分支上完成并挑选到测试上。
偶尔需要手动合并。
我想改进这个工作流程。目前，我的存储库在两个分支上充满了并行的相同更改。
我想我更愿意这样做（对于测试 - >产品）：
一旦开发准备好，在产品的头部创建一个新分支
将这组开发更改折叠为新分支上的单个更改
将此新分支合并到 Prod 上。请记住，它们的共同祖先是在使 Test 与 Prod 不同的更改之前
git rebase -i 似乎可以完成这项工作，但我必须承认 git rebase 是我的pons asinorum，不知怎的，我已经多次弄乱了我的树。
所以我的问题是：
请在产品的限制范围内提出更好的方法。
如果我的首选方法可行，有人可以建议
git rebase -i的正确参数吗？
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:
Please suggest a better way, within the constraints of the product.
If my preferred approach is viable, could someone please suggest the correct parameters for
git rebase -i?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
关于测试和生产之间的差异，检查是否可以检测到您是否处于一种环境或另一种环境中。
对于具有特定于平台的内容的文件，这将允许在签出时使用 通过涂抹脚本过滤驱动程序。
这样，您就不必为了分离几乎相同的代码集而维护分支。
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.
我的建议是更频繁地将开发（测试）和生产（Prod）分支相互合并，而不是选择性地跨分支进行更改。特别是，当在产品中进行更改时，请经常将它们合并（至少每天一次）到测试中。当测试中的更改准备就绪时，将它们合并到产品中。
您在批准后从测试中挑选提交到生产中也表明您的提交没有很好地分割，而是每个提交都有很大的差异。这使得使用历史记录来调试问题变得困难，并且几乎不可能恢复单个更改（通过恢复单个提交）。
我认为通过改变工作流程中的这两件事，如何管理开发和生产分支的更大问题将变得更加明显。
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.