git流分支模型分支 [英] git flow branching model branching

查看:150
本文介绍了git流分支模型分支的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在阅读和重新阅读有关成功的git模型的文章( git flow ),并且在开发分支时遇到一些困惑。他说:


开始使用新功能时,请从develop分支中分支出去。



$ git checkout -b myfeature develop





  1. 他从哪开始?我检查了'develop'分支吗?

  2. 'myfeature'跟踪我的本地'develop'分支或远程'origin / develop'分支后的'develop'是什么? b $ b
  3. 如果我在创建'myfeature'时在'develop'分支中开始,那么最终是否需要'develop'?
  4. 'myfeature'是否将当前开发分支的头部?

  5. 如果我只想在开发服务器上查看我的更改,是否需要合并到本地开发或远程开发中?

我正在试着围住它 - 再次重新阅读并根据此模型找到一些屏幕录像。

解决方案


  1. 无所谓,因为他明确地设置了基本提交(开发)。命令运行后,无论以前检出什么内容,他都将位于 myfeature 分支中。

  2. develop 是一个本地分支,可能跟踪 origin / develop ,您的远程跟踪分支。

  3. 不。 git checkout -b myfeature ,没有明确的起点,将在 HEAD 处创建一个新分支。如果您位于 develop 分支的顶端,则 myfeature 将基于开发

  4. 不完全。 myfeature 引用与的提示开发引用相同的提交。没有什么是复制的。当您签出 myfeature 时提交更改时, myfeature 提示将更新为新的提交。 develop 不会改变。
  5. 如果您想在远程位置查看您的更改,则需要推送至偏远的地点。如果你想完成你的功能,git-flow-style,我是猜测你想要在开发部分包含完成的功能:切换到开发,合并到 myfeature ,删除 myfeature ,并将现在更新的开发推出到原点 code>。


更多答案:


  • 如果我从develop中分支出来,就像做一样; git checkout -b myfeature在不开发的时候开发?



新分支从开发在这两种情况下。 ( git branch )以同样的方式工作,除非它不会像 git checkout -b 那样切换到新分支。 )为了完成我的功能,我将签出开发> git pull> git merge myfeature> git push origin(aka)。

虽然 git push origin


>并不总是aka起源/发展。默认情况下, git push origin 将推送所有与原始分支具有相同名称(或已设置为跟踪)的分支。 (你可以使用 push.default config设置来改变默认值。) git push origin develop 会将你的本地开发分支到原产地的开发分支,这就是你想要的。




  • 如果我在合并之前不拉动,覆盖其他人提交的新提交的风险,是正确的吗?



只有当您强制推送时不要那样做)。你可以在合并后进行拉动,但是你基本上会合并两次。如果你不这样做,它会更好地完成拉取操作,但是如果你不这样做的话,你不会有丢失数据的风险。


  • 有没有什么时候我会合并开发为myfeature?



当然,如果有人推出更新到 origin / develop ,并且您想要合并它们的更改。从本质上讲,如果你想保持你的功能分支是最新的,你还没有准备好将 develop 合并到 myfeature 合并到 develop




  • 每个myfeature都合并成一个发布分支,还是应该总是重新开发?



在git-flow系统中, myfeature 应该总是回到 develop ,并且发布分支总是从 develop 开始。 develop 应该是准备好进行外部曝光的更改的分支 - 用于集成测试,候选版本发布 - 以及代表当前开发状态​​的分支在项目中。这是所有新东西的起点。您不希望在 myfeature 分支和一些随机发布分支中工作,但不希望在 develop 行。


I've been reading and re-reading the post about a successful git model (git flow) and I'm confused about a couple things when working off a develop branch. He says:

When starting work on a new feature, branch off from the develop branch.

$ git checkout -b myfeature develop

  1. What branch is he starting in? My checked out 'develop' branch?
  2. Is the 'develop' after 'myfeature' track my local 'develop' branch or the remote 'origin/develop' branch?
  3. If I start in my 'develop' branch when I create 'myfeature' do I need the 'develop' at the end?
  4. Does 'myfeature' copy the current HEAD of the develop branch?
  5. If I only wanted to see my changes on a dev server, do I need to merge into my local develop or remote develop?

I'm trying to wrap my head around it - off to re-read it again and find some screencasts based on this model.

解决方案

  1. Doesn't matter, because he explicitly set the base commit (develop). After the command is run, he'll be on the myfeature branch, regardless of what was checked out before.
  2. develop is a local branch that probably tracks origin/develop, your remote tracking branch.
  3. Nope. git checkout -b myfeature, without an explicit starting point, will create a new branch at your HEAD. If you're at the tip of the develop branch, myfeature will be based on develop.
  4. Not exactly. myfeature references the same commit that the tip of develop references. Nothing is "copied". When you commit changes while myfeature is checked out, the myfeature tip will be updated to the new commits. develop will not change.
  5. If you want to see your changes at a remote location, you need to push to the remote location. Just merging into a local branch won't do anything for the remote side.

    If you want to "finish" your feature, git-flow-style, I'm guessing you want the Incorporating a finished feature on develop section: Switch to develop, merge in myfeature, delete myfeature, and push the now-updated develop out to origin.

[e] More answers:

  • If I branch from within develop, it's the same as doing; git checkout -b myfeature develop when not in develop?

The new branch starts from develop in both cases. (git branch works the same way, except it won't switch you to the new branch like git checkout -b does.)

  • And to finish myfeature, I would checkout develop > git pull > git merge myfeature > git push origin (aka origin/develop)?

Roughly, though git push origin is not always "aka origin/develop". By default git push origin will push all the local branches that have the same name (or have been set up to track) the branches on origin. (You can change the default with the push.default config setting.) git push origin develop will push just your local develop branch to origin's develop branch, which is what you want.

  • If I don't pull before the merge, I run the risk of overwriting new commits made by others, correct?

Only if you force the push (which, seriously, don't do that). You can do the pull after the merge, but then you'd essentially be merging twice. It works out better to do the pull first, but you're not at risk of losing data if you don't.

  • Is there ever a time when I would merge develop into myfeature?

Sure, if someone else has pushed out updates to origin/develop and you want to incorporate their changes. Essentially, you would merge develop into myfeature if you want to keep your feature branch current and you're not ready to merge into develop.

  • And does myfeature every get merged into a release branch or should it always go back into develop?

In the git-flow system, myfeature should always go back to develop, and release branches always start from develop. develop is supposed to be the branch for changes ready for external exposure--for integration testing, release candidates, whatever--as well as the branch that represents the current state of development in the project. It's the starting point for all the new stuff. You don't want to end up with your work in the myfeature branch and some random release branch, but not the main develop line.

这篇关于git流分支模型分支的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆