如此简短的故事我正在为应用程序管理一些代码的GIT回购。该应用程序没有任何测试。其中一个开发人员将一个功能分支直接合并到master中，Jenkins将其部署到stage。此功能分支有数周的更改，并多次合并到master分支。所以我从假期回来，发现一些功能被破坏，并添加了未准备好黄金时段的功能。我设法通过恢复合并和提交来梳理坏代码。 我想运行这个固定的代码库并手动测试它的垃圾。 PM想要了解现场的情况并将其放入GIT回购中。 这似乎是错的。有没有人有任何其他解决方案或评论？
答案 0 :(得分：1)
我不明白PM想要做什么。
虽然我相信一个“维护良好”的Git仓库每个功能都有一个分支，包括修复，一旦稳定并通过测试就会合并。
我知道并想象坚持下去是多么困难。所以我猜你现在拥有的是一个回购，其中你不知道任何提交可能代表什么，因为它很乱并且你添加了回复（个人认为应该尽可能避免回复）。
所以你想要有稳定的东西吗？我建议，即使我对它的经验很少，也要从历史上的稳定提交开始。从中分支并将其称为“稳定”，这将成为您的主要分支。从引入新功能或错误的提交中连续合并。对于每个，提交修复，直到它稳定，并在下一次错误提交之前重新定义这些修复。
例如，之前：
A（稳定） - B（feature1，bugged） - C（feature2，更多错误） - D（更糟）
后：
A - B - B1 - B2 - C - C1 - D - D1
（以便A，B2，C1，D1是稳定的里程碑）。总的来说，你可以玩rebase，merge和cherry-pick来执行你想做的事情。这篇文章：Git Cherry-pick vs Merge Workflow告诉您，如果您对其他人不满意，最好使用合并，但差异很小，非常有用。
希望你能解决问题