feature当当前分支中的更改feature尚未准备好提交时，是否有任何方法可以从一个分支切换到另一个分支？
我经常发现自己处于这样一种情况：在实现新功能或修复错误时我没有想法，我需要切换齿轮并从事其他事情。但是，我不知道如何切换分支而不丢失迄今为止我所做的所有未提交的工作。
我正在与一个团队一起使用 Git Flow。我们都从功能开发中分支出来，并在代码审查后合并回来。它对我们来说效果很好，但是我们现在有一个功能需要开发人员一个多月才能完成。这段时间我们将发布一些版本。
有几个问题可以推动这一点：
我刚刚开始尝试设置 Bonobo Git 服务器。我没有看到任何在其中设置分支的方法？我看过关于分支文件夹权限的讨论，所以我知道这是可以做到的。有没有办法从 Web 界面创建分支？
我将使用 SourceTree 与其交互，并使用 GitFlow 来处理功能和分支。因此不确定是否需要在 Bonobo 中进行其他一些初始设置来设置其中的主/开发（和其他）分支和功能。
另外，我们一直在使用最近崩溃的 gitlab 本地服务器。因此，我们存储库的唯一工作副本是客户端计算机上的副本。我需要将存储库放回 Bonobo Git 服务器。如果有人有任何最佳步骤操作可以做到这一点，我也希望知道如何做到这一点。
Git-Flow 假设开发人员在本地存储库中创建功能分支。JIRA 中的按问题分支工作流程假设开发人员在远程存储库中创建功能分支。这些工作流程可以协同工作吗？另外，Eclipse Git-Flow 插件是否可以与 JIRA 中的按问题分支工作流程配合使用？
如何创建新分支以包含待处理的拉取请求，同时在推送新 PR 时不会产生问题？例如，我不希望第一个 PR 的更改在合并第二个 PR 时产生冲突。
考虑从第一个功能分支分支或将第一个功能合并到第二个分支，但不确定哪个是更好的选择。
有时我需要（为了使我的开发更快）在我的代码中编写一些东西。这可以是凭证，也可以只是允许我测试某些功能的黑客攻击。由于多种原因，我从来不想将此代码推送到主代码库甚至开发分支。一段时间以来，我一直在使用“git-assume-uncched”命令，但在合并、变基等操作之后，这些命令可能会混淆，你可能会推送一些你不想要的东西。有没有一种很酷、干净的方法来实现这一目标？也许有一些命令警告我必须记住在推送之前签出某些文件或类似的命令？有任何想法吗？
git 新手，正在尝试学习 GitFlow。使用 GitFlow，您经常会从develop分支上切下一个发布分支，以便您可以隔离新更改的子集并将它们部署到某个临时/非生产环境。但我实际上找不到可靠的文档来说明剪切这些发布分支的正确过程（命令方面）。是吗：
git checkout develop
git pull
git checkout -b release/1.1.3
git add .
git commit -m "Cutting release branch for v1.1.3."
git push
或者是：
git checkout develop
git pull
git checkout -b release/1.1.3
git push origin release/1.1.3
或者是别的什么？为什么？！
我们的团队正在使用 git flow，并且我们大约每两个月进行一次持续发布。我对什么时候应该创建发布分支有点困惑。
例如，在以下情况下，上一个版本有一个错误，应该在这个版本中修复，我应该首先创建发布分支并从发布分支创建错误修复分支，还是只是从开发创建它，进行所有功能开发并合并回开发，然后从开发创建发布分支？
我应该直接将小错误推送到发布分支而不创建错误修复分支吗？
我是否应该将来自功能分支或错误修复分支的开发中的一个提交合并到发布分支？
\n\n\n当完成的功能和修复已准备好发布时，它们会合并回开发分支
\n
据我了解，这意味着当开发人员对自己的工作充满信心时，功能就会被合并以进行开发。
\n\n\n\n\n当需要发布版本时，会从开发中创建发布分支
\n
在这条线上，开发分支中的功能预计将被发布。
\n\n以上一切都很好，直到某个功能被 QA 测试确定尚未“准备好”发布，或者可能快到了该功能可以移至下一个版本的发布日期。
\n\n我知道做一个git revert可以对此有所帮助。我碰巧很久以前就经历过这种情况（不过我已经忘记了那段时间我做了什么），但我一直在使用实验性的自定义工作流程来防止类似的情况发生。
实验性自定义工作流程Worlflow 1
\n\n我正在试验的流程几乎与 gitflow 相同，除了“功能合并以开发”部分之外。在此实验工作流程中，它被替换为“合并待开发的已验证功能”
\n\n流程变成这样：
\n\n它对我来说工作正常，但有一个小问题。它会在每次变基时创建重复的提交。我已经尝试过cherry-pick，merge（与 ff），但pull --rebase结果都是相同的。
我计划测试另一种方法，以避免每次变基时重复提交，但我认为它还会存在另一组问题。
\n\n和上面的工作流程几乎一样
\n\n工作流程2
\n\n所有要发布或由 QA 测试的功能都合并 …
我有一个像这样的 Gitflow 分支结构：
我正在使用 CircleCI 并启用“仅构建拉取请求”功能。启用此功能后，它将构建所有拉取请求并始终构建默认分支。所以会发生以下情况：
feature/header运行developCircleCI 测试develop合并后，来自into的 PRmaster也运行 CircleCI 测试master是默认分支我的问题是我想develop成为我的默认分支，因为在 Gitflow 中创建的 99% 的 PR 都会进入develop. 有没有办法禁用“仅构建拉取请求”并过滤工作流程以在 CircleCIconfig.yml文件中的拉取请求上运行？
我的工作流程之一如下所示（已按分支过滤）：
deploy_qa:
jobs:
- checkout:
filters:
branches:
only: master
- dependencies_production:
requires:
- checkout
- build_production:
requires:
- dependencies_production
- deploy_qa:
requires:
- build_production
- restart_qa:
requires:
- deploy_qa