git flow分支模型分支

Question

我一直在阅读并重新阅读有关成功的git模型（git flow）的帖子，我在处理开发分支时对一些事情感到困惑。他说：

  

开始处理新功能时，从开发分支分支。

     

$ git checkout -b myfeature develop

1. 他从哪个分支开始？我检查了'develop'分支？
2. 'myfeature'之后的'develop'是跟踪我当地的'develop'分支还是远程'origin / develop'分支？
3. 如果我在创建'myfeature'时从我的'develop'分支开始，我最后需要'develop'吗？
4. 'myfeature'是否会复制开发分支的当前HEAD？
5. 如果我只想在开发服务器上看到我的更改，是否需要合并到我的本地开发或远程开发？

我正试图绕过它 - 关闭它再次重新阅读并找到一些基于此模型的截屏视频。

Answer 1

1. 无关紧要，因为他明确设置了基本提交（develop）。运行命令后，无论以前签出什么，他都会在myfeature分支上。
2. develop是一个本地分支，可能跟踪您的远程跟踪分支origin/develop。
3. 不。如果没有明确的起点，git checkout -b myfeature会在HEAD处创建一个新分支。如果您位于develop分支的顶端，则myfeature将基于develop。
4. 不完全是。 myfeature引用develop提示引用的相同提交。什么都没有“复制”。在签出myfeature时提交更改时，myfeature提示将更新为新提交。 develop不会改变。

5. 如果要在远程位置查看更改，则需要将其推送到远程位置。只是合并到本地分支不会为远程端做任何事情。

   如果你想“完成”你的功能，git-flow-style，我猜你想要将完成的功能纳入开发部分：切换到develop，合并在myfeature中，删除myfeature，然后将现已更新的develop推送到origin。

[e]更多答案：

• 如果我从开发中分支，它就像在做; git checkout -b myfeature在不开发时开发？

在两种情况下，新分支都从develop开始。 （git branch的工作方式相同，只是它不会像git checkout -b那样切换到新的分支。）

• 为了完成我的功能，我会结帐开发＆gt; git pull＆gt; git merge myfeature＆gt; git push origin（又名origin / develop）？

粗略地说，虽然git push origin并不总是“aka origin / develop”。默认情况下，git push origin将推送具有相同名称（或已设置为跟踪）原始分支的所有本地分支。 （您可以使用push.default配置设置更改默认值。）git push origin develop会将您的本地开发分支推送到origin的开发分支，这就是您想要的。

• 如果我在合并之前没有提取，我冒着覆盖别人提交的新提交的风险，对吗？

只有你强行推动（严重的是，不要这样做）。您可以在合并后执行拉动，但之后您基本上会合并两次。首先进行拉取会更好，但如果不这样做，则不会有丢失数据的风险。

• 有没有时间我将合并发展为myfeature？

当然，如果其他人推送了origin/develop的更新，并且您想要合并他们的更改。基本上，如果您希望将功能分支保持最新状态并且尚未准备好合并到develop，则可以将myfeature合并到develop。

• 并且myfeature每次都被合并到一个发布分支中，还是应该总是重新开发？

在git-flow系统中，myfeature应始终返回develop，发布分支始终从develop开始。 develop应该是准备好进行外部暴露的变更分支 - 用于集成测试，发布候选者，等等 - 以及代表项目当前开发状态​​的分支。这是所有新东西的起点。您不希望最终在myfeature分支和一些随机发布分支中工作，而不是主develop行。

Answer 2

当您使用显式起点时，您当前使用的分支无关紧要。语法是：

git branch <branchname> [<start-point>]

如果你没有指定一个起始点，git将分支你当前所在的任何分支。但是，使用明确的起始点，您可以在.git / refs / heads中列出的任何头部创建新分支。

至于其他人：

• 开发应该是origin / develop的跟踪分支。
• 当您可视化历史记录时，您的新功能分支最初看起来像是开发的同义词，因为提交引用指针在您进行某些提交之前是相同的。
• 列表项目5超出了您当前问题的范围。问别人。 ：）

Answer 3

在这里很晚才进入，但你应该考虑你所引用的模型被许多人视为不良做法的可能性。请参阅此blog post。

它的要点是，虽然您可以将GIT用于类似于非分布式版本控制系统的分支模型，但这并不意味着您应该这样做。如果您打算这样做，请问问自己，我是否应该首先选择GIT。没有快进的合并尤其受到批评，因为它剥夺了GIT提供的许多优势/工具。

我还没有意见。我自己就是消化所有这些东西。