【发布时间】：2018-05-07 13:29:20
【问题描述】：
我有一个基础develop 分支，并创建一个新的feature-a 分支。完成后，我提交更改并推送，然后发出合并请求。虽然该合并请求的结果未决，但我想继续处理新的 feature-b 分支，该分支扩展了 feature-a 分支中的代码。这可能吗？如果可以，怎么做？
【问题讨论】：
标签： git git-branch git-merge
【发布时间】：2018-05-07 13:29:20
【问题描述】：
是的，当然是。
假设您使用feature-a 只是为了确保输入
git co feature-a
要检查你是否在那个分支上，你可以输入
git branch -a
所以现在你 100% 肯定在正确的分支上，然后从那里输入：
git co -b feature-b
现在您可以从 feature-a 进行更改
git log
要查看feature-a 的最新更改，您可以使用git branch -a 来验证您是否在名为feature-b 的新分支上
重要的 #1 是当您使用 git co -b new-branch-name 创建一个“新”分支时，它将包含您当前所在分支的所有提交。
然后，重要的事情 #2 在创建拉取请求时确保选择正确的“基础”分支，因为它不会自动正确设置。它还会列出所有新的提交，当您更改到正确的基础分支时，您只会看到新分支中的“所需”提交。
【讨论】：
-
只要确保你还在你的错误跟踪/项目管理系统中创建了一个链接/依赖关系，这样你就不会在功能 A 之前发布功能 B，因为 git 的工作方式是发布功能 B无论 A 的分支状态如何，都会隐式地拉取特性 A。
-
一般来说最好避免这种情况。要么您在分支 A 中创建了一些您也想在分支 B 中使用的框架，在这种情况下，您至少应该记下在未来尝试以不同方式组织事物，或者您实际上是在扩展 A 的新功能，在在这种情况下，我认为您对问题的组织有点奇怪。 在实现一个问题后会有一些松弛，包括代码审查、拉取请求、测试等，如果您需要立即继续开发该功能，您可能希望完全以不同的方式工作。跨度>
-
@LasseVågsætherKarlsen 感谢 cmets。我已经更新了答案。
-
是的，我的 cmets 更适合 OP，您的回答本来就是完美的。尽管我的建议相反，但我们自己这样做，但我们会尽量减少这些情况，因为它们开始在各处创建依赖关系。 “你不能在A之前发布C，你必须在C之后发布B，但是C是先测试的，客户想要C等等。”
-
@LasseVågsætherKarlsen 是真的！我知道。我的工作主要需要它。所以我可以尝试一些东西，它被保存了，同事可以评论它。只要不搞砸，它总是很棒:)