Question

我的开发分支中有一些更改，我想为其创建一个新的功能分支。我可以这样做：

//switch to branch
git checkout -b uploadFeature develop

//push my changes to the feature branch (do this many times)
git push origin uploadFeature

//merge the feature branch into the master
git checkout develop
git merge --no-ff uploadFeature

这是正确的工作流程吗？还有什么我需要担心的吗？如果我团队中的其他人正在检查主人，我是否需要每天将更改从主人转移到功能部门？会发生什么？

Answer 1

您的合并命令将无效，因为您需要重新开发回原点/开发。

假设您的历史记录看起来像这样（在合并命令之前）：

C (develop, uploadFeature, HEAD)
|
B
|
A (origin/develop)

您希望提交B和C来表明它们是在功能分支中完成的，而不是直接在开发中完成。

您需要在合并之前执行此操作：

git reset --hard origin/develop

这将使您的历史记录如下：

C (uploadFeature)
|
B
|
A (develop, HEAD, origin/develop)

然后你可以执行你的合并命令，历史记录将如下所示：

D (develop, HEAD)
|\
| \
| C (uploadFeature)
| |
| B
| /
|/
A (origin/develop)

至于您的所有其他问题，大部分问题都取决于您的工作流程。

Answer 2

所以你目前正在使用 develop ，对HEAD提交进行未提交的工作副本更改。

$ git checkout -b feature

将创建一个名为 feature 的分支，从相同的HEAD提交开始，然后切换到它。您的工作副本不会更改

$ git add {any new files}
$ git commit

将使用您的新更改在功能上创建本地提交。 develop 分支未更改， feature 现在是 develop 之前的一次提交。

$ git push -u origin feature

将创建一个名为feature的远程分支，将提交推送到它，并更新本地分支以跟踪远程分支。

你的合并很好，虽然我不确定你为什么要禁止快进。

如果我团队中的其他人正在检查主人，我是否需要每天将更改从主人转移到功能部门？会发生什么？

除非他们的改变影响你的。

通常，我建议如上所述进行简单合并 - 如果失败，然后将 develop 合并到功能，修复任何冲突并在功能分支上重新测试，然后重新执行原始合并。

Answer 3

该工作流程看起来不错。如果你或其他人推入master，那么就会出现分歧，你必须合并这些更改，git使得合并更改变得相对容易，特别是如果你使用小提交。

没有必要每天都进行更改，但是小的合并会让您在早期检测到不兼容的更改，而不是在进行大型合并时;如果你的特征分支将是非常长寿的，那么定期从master中合并，对于短期特征分支通常是明智的，这通常是不必要的。

有些团队会进行改造而不是合并，这样您就可以完成更清晰的历史记录，并且让其他只能在master上工作的人更有可能进行快进合并。

如何从我尚未签入的开发分支中的代码更改创建功能分支？

3 个答案: