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