git - 管理可能需要多个 rebase 操作的长期运行功能分支的正确方法？

Question

我知道你不应该在你变基之前将更改推送到你的遥控器，我有点理解为什么。但是，设想以下场景：

• 制作功能分支
• 做工作
• 变基
• 推送和文件拉取请求
• 一切都好，对吧？错误的！集成管理器通过评论拒绝您的功能
• 修复您的功能
• 与此同时，主人已经继续前进，所以你再次变基......
• 哎呀！现在您正在重新设置已经推送的分支！

处理这个问题的正确方法是什么？

Answer 1

“在你变基之前，你不应该将更改推送到你的遥控器”

我完全不同意这种说法；你所描述的都不应该保证一个变基。

您所描述的问题听起来好像您的遥控器上只有一个master分支，并且您一直在分支功能分支。这违背了Git Flow。

不要担心长时间运行的特性分支——这是完全正常的，你可以重复将这样的分支推送到origin. 由于 Git 中的备份（您提到过），这甚至是推荐的。

您需要遵循典型的 Git 流程：

1. 你有一个master连接到你的生产环境的分支，
2. 您develop从您的master分支分支
   （并将其连接到开发和测试环境）。
3. 你把你的每一个feature分支都从develop，而不是master，
4. 在任何时候，无论该功能是否完整，您都可以提交origin/feature/your-branch，
5. 当该功能完成后，您可以develop通过拉取请求合并到。
   这是唯一应该发生冲突的地方！
   • 如果存在冲突，您可以在本地分支上修复它们，方法是pull将分支 ingdevelop到本地功能分支中。您可能需要先进行stash更改。然后你可以push回到你的本地分支origin——这个特性分支还没有被合并。
   • 冲突解决后，分支被合并到develop.
6. develop然后部署到您的开发环境中（最好通过持续集成工具自动部署，例如 Jenkins 或 TeamCity）。这样，开发环境始终具有所有最新功能。

7. 当您彻底测试了您的功能时，您创建了功能的发布版，并将该版本发布到master（部署到生产中）。此时将 a 添加tag到分支上也很有用，因此您可以确切地知道当前正在生产的版本。

这样，您将永远不会遇到origin/feature/your-branch在合并之前将代码推送给任何其他开发人员或环境的情况。也意味着特性合并到 后develop，你的生产环境仍然不会包含这个特性，所以你不用担心；在功能到达生产服务器之前，您可以自由地测试该功能。