0

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

//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

这是正确的工作流程吗？我还有什么需要担心的吗？如果我团队中的其他人正在检查 master 会发生什么，我是否需要每天将 master 中的更改拉入功能分支？

4

3 回答 3

2

您的合并命令将不起作用，因为您需要将开发重置回原点/开发。

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

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)

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

于 2013-08-02T14:24:22.917 回答
1

因此，您目前正在开发中，针对 HEAD 提交进行了未提交的工作副本更改。

$ git checkout -b feature

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

$ git add {any new files}
$ git commit

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

$ git push -u origin feature

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

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

如果我团队中的其他人正在检查 master 会发生什么，我是否需要每天将 master 中的更改拉入功能分支？

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

通常，我建议像上面那样进行简单的合并 - 如果失败，则合并开发到feature，修复任何冲突并在 feature 分支上重新测试，然后重新进行原始合并。

于 2013-08-02T14:15:58.347 回答
1

该工作流程看起来不错。如果你或其他人 push 到 master 中，就会出现分歧，你将不得不合并更改，git 使合并更改相对容易，特别是如果你使用小提交。

不必每天都拉取更改，但是小合并可以让您及早发现不兼容的更改，而不是在进行大合并时；如果您的功能分支将非常长寿，那么定期从 master 合并通常是明智的，对于短暂的功能分支，这通常是不必要的。

一些团队做一个变基而不是合并，这样你就可以完成一个更清晰的历史记录，并使其他只在 master 上工作的人更有可能进行快进合并。

于 2013-08-02T14:32:02.873 回答