我们公司目前正在使用简单的主干/发布/修补程序分支模型,并希望了解哪些分支模型最适合您的公司或开发过程.
工作流程/分支模型
以下是我所看到的三个主要描述,但它们彼此部分相互矛盾,或者不足以解决我们遇到的后续问题(如下所述).因此,我们的团队到目前为止默认不是那么好的解决方案.你做得更好吗？
合并与变基(纠结与连续历史)
是应该pull --rebase还是等待合并回到主线直到你的任务完成？我个人倾向于合并,因为这保留了一个任务开始和完成的基础的视觉图示,我甚至更喜欢merge --no-ff这个目的.然而,它有其他缺点.还有许多人没有意识到合并的有用属性 - 它不是可交换的(将主题分支合并到master中并不意味着将master合并到主题分支中).
我正在寻找一个自然的工作流程
有时会发生错误,因为我们的程序无法通过简单的规则捕获特定情况.例如,早期版本所需的修复当然应该足够下游,以便可以将上游合并到所有必要的分支中(这些术语的使用是否足够清楚？).然而,在开发人员意识到它应该被放置在更下游之前,并且如果已经推送(更糟糕的是,合并或基于它的某些东西)之后,修复使其成为主人,那么剩下的选项就是挑选,其相关的危险.您使用了哪些简单的规则？同样在这包括一个主题分支的尴尬必然排除其他主题分支(假设它们从共同基线分支).开发人员不希望完成一个功能来启动另一个功能,感觉就像他们刚写的代码不再存在
如何避免创建合并冲突(由于挑选)？
创建合并冲突的可靠方法似乎是在分支机构之间进行挑选,它们永远不会再次合并？在任一分支中应用相同的提交(如何执行此操作？)可能会解决这种情况？这是我不敢推动基于合并的工作流程的一个原因.
如何分解成外用分支？
我们意识到从主题分支组装完成的集成是很棒的,但是我们的开发人员经常工作没有明确定义(有时像"戳"一样简单),如果某些代码已经进入"misc"主题,根据上面的问题,它不能再被带出去了吗？您如何使用定义/批准/毕业/发布您的主题分支？
代码审查和毕业等适当的程序当然是可爱的.
但是我们根本无法保持足够的东西来管理这个 - 任何建议？整合分支,插图？
以下是相关问题列表:
还要看看Plastic SCM在任务驱动开发上写的内容,如果不是Plastic的选择,请研究nvie的分支模型及其支持脚本.
自从我从svn切换到git后,我每次重新编译时都开始做更多的提交,我的测试通过了我的工作.最后我最终按功能提交功能.
我还使用像emacs,wordpress等git跟踪一些其他项目.我看到他们不经常提交.所以我想知道你怎么承诺？
据我所知,当我使用时git pull --rebase,git将重新编写历史记录并在我刚从中提取的分支中的所有提交之后移动我的本地提交.
我不明白的是这将是一件多么糟糕的事情.人们谈论陷入困境git pull --rebase,你最终会找到一个别人无法忍受的分支.但我不明白这是怎么回事,因为你所做的就是在你所从的分支上重播你当地的,尚未公开的提交.那么,那里的问题是什么？
我找不到任何使用git管理版本的"正确"方法.说,我有master,release-1,release-2和release-3分支.版本1已经发布,我只对其进行了错误修正和发布版本标记.第2版将很快发布,我主要在这个分支上发展,而在3年我开发了将来需要的东西.
当我在release-2上添加一些功能时,它也应该转到3,但不是1,我应该:
当我需要在所有版本中进行更改时,我是否应该在master上进行更改并将其挑选到所有分支中？
我是否应该掌握最新的(第3版分支)或者第3版的开发人员,并在我需要发布4分支之前合并到主服务器？
当我在发行版1或版本2上修复时,我应该合并或者选择它来掌握或者说它？
我不太确定我什么时候应该挑选,什么时候应该合并,如果分支之间的代码流正确的话.
我开始在公司内进行少量开发.我打算使用Git进行版本控制,我很想知道人们在他们的小组中使用的版本是什么准则或标准,类似于编码标准通常是在小组内写的.
我假设会有类似的东西;
显然,很多这将取决于您使用的VCS以及您如何构建它.