[英]Git Version Control and Branching
This isn't a code question, more of a 'best practices' question. 这不是代码问题,更多是“最佳实践”问题。
I'm using GitHub and BitBucket, when you have the master that will be your live working code. 当您拥有将成为您的实时工作代码的母版时,我将使用GitHub和BitBucket。
To build upon or fix bugs, is it best to create a branch? 要建立或修复错误,最好创建一个分支吗?
When that branch is ready to merge would it be best to merge and then delete that branch? 当该分支准备合并时,最好合并然后删除该分支?
If you merge, how do you keep note in the master of what branch that master was pushed from? 如果合并,如何在主节点中记录主节点从哪个分支推送?
Thanks in advance 提前致谢
You could follow either Github Flow or git flow . 您可以按照Github Flow或git flow进行操作 。 I use a mix between both, but both are great depending on how you work. 我在两者之间混合使用,但两者都取决于您的工作方式。
For Github Flow, you would do: 对于Github Flow,您可以执行以下操作:
master
always deployable; 使master
始终可部署; master
. 合并以master
。 For git flow, you would do something like: 对于git flow,您可以执行以下操作:
master
mirroring your production environment; 保持master
反映您的生产环境; develop
branch for non-deployed but ready things; 有一个未部署但准备就绪的develop
分支; git checkout -b release-1.2 develop
git checkout master
git merge --no-ff release-1.2
git tag -a 1.2
Then deploy master
. 然后部署master
。
For git flow, when you are working on a hotfix, you would commit your fixes on a separate branch before tagging the new release, and merge changes back: 对于git flow,当您处理修补程序时,可以在标记新版本之前将修补程序提交到单独的分支上,然后将更改合并回去:
git checkout -b hotfix-1.2.1 master
; git checkout -b hotfix-1.2.1 master
; git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
You would also deploy master
. 您还将部署master
。
IMO: 海事组织:
To build upon or fix bugs, is it best to create a branch? 要建立或修复错误,最好创建一个分支吗?
Yes, create a branch for each bugfix, upgrade or modification. 是的,为每个错误修正,升级或修改创建一个分支。 Examples: master_bugfixing
, mybranch_new_feature
and so on. 示例: master_bugfixing
, mybranch_new_feature
等。
edit: why I think it's a good idea to create a branch - quotes from Visualized Git practices for team: branch, merge, rebase - 编辑:为什么我认为创建分支是个好主意- 团队可视化Git做法的引文:分支,合并,变基 -
When that branch is ready to merge would it be best to merge and then delete that branch? 当该分支准备合并时,最好合并然后删除该分支?
I always delete unused branches, ie branches already merged. 我总是删除未使用的分支,即已经合并的分支。
If you merge, how do you keep note in the master of what branch that master was pushed from? 如果合并,如何在主节点中记录主节点从哪个分支推送?
You could add a message during merge with git merge -m <msg>
. 您可以在合并期间使用git merge -m <msg>
添加一条消息。
A hint for a branching model: A successful Git branching model 分支模型的提示: 成功的Git分支模型
To build upon or fix bugs, is it best to create a branch? 要建立或修复错误,最好创建一个分支吗?
yes, it's the best practice to create a separate branch in order to build or fix your bugs. 是的,最佳实践是创建一个单独的分支以构建或修复您的错误。
When that branch is ready to merge would it be best to merge and then delete that branch? 当该分支准备合并时,最好合并然后删除该分支?
It depends your type of project, however there's no problem in deleting branches that have been merged in. All the commits are still available in the history. 这取决于您的项目类型,但是删除已合并的分支没有问题。所有提交在历史记录中仍然可用。
If you merge, how do you keep note in the master of what branch that master was pushed from? 如果合并,如何在主节点中记录主节点从哪个分支推送?
Again commits history is saved in Git, so we can keep track of which branch is mereged with Master branch. 再次将提交历史记录保存在Git中,因此我们可以跟踪使用Master分支定义了哪个分支。
Hope you got enough clarification on your queries. 希望您对查询有足够的澄清。
For more information, refer git-scm 有关更多信息,请参考git-scm
Thank you. 谢谢。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.