相关疑难解决方法(0)

Git分支模型适合您？

我们公司目前正在使用简单的主干/发布/修补程序分支模型,并希望了解哪些分支模型最适合您的公司或开发过程.

工作流程/分支模型

以下是我所看到的三个主要描述,但它们彼此部分相互矛盾,或者不足以解决我们遇到的后续问题(如下所述).因此,我们的团队到目前为止默认不是那么好的解决方案.你做得更好吗？
合并与变基(纠结与连续历史)

是应该pull --rebase还是等待合并回到主线直到你的任务完成？我个人倾向于合并,因为这保留了一个任务开始和完成的基础的视觉图示,我甚至更喜欢merge --no-ff这个目的.然而,它有其他缺点.还有许多人没有意识到合并的有用属性 - 它不是可交换的(将主题分支合并到master中并不意味着将master合并到主题分支中).
我正在寻找一个自然的工作流程

有时会发生错误,因为我们的程序无法通过简单的规则捕获特定情况.例如,早期版本所需的修复当然应该足够下游,以便可以将上游合并到所有必要的分支中(这些术语的使用是否足够清楚？).然而,在开发人员意识到它应该被放置在更下游之前,并且如果已经推送(更糟糕的是,合并或基于它的某些东西)之后,修复使其成为主人,那么剩下的选项就是挑选,其相关的危险.您使用了哪些简单的规则？同样在这包括一个主题分支的尴尬必然排除其他主题分支(假设它们从共同基线分支).开发人员不希望完成一个功能来启动另一个功能,感觉就像他们刚写的代码不再存在
如何避免创建合并冲突(由于挑选)？

创建合并冲突的可靠方法似乎是在分支机构之间进行挑选,它们永远不会再次合并？在任一分支中应用相同的提交(如何执行此操作？)可能会解决这种情况？这是我不敢推动基于合并的工作流程的一个原因.
如何分解成外用分支？

我们意识到从主题分支组装完成的集成是很棒的,但是我们的开发人员经常工作没有明确定义(有时像"戳"一样简单),如果某些代码已经进入"misc"主题,根据上面的问题,它不能再被带出去了吗？您如何使用定义/批准/毕业/发布您的主题分支？
代码审查和毕业等适当的程序当然是可爱的.

但是我们根本无法保持足够的东西来管理这个 - 任何建议？整合分支,插图？