我们使用git作为版本控制,我们使用它的方式如下:
我们的主要分支是生产,对于每个新问题或升级,开发人员应该从生产分支创建新分支,更新代码并测试它,然后将更改提交到新分支。之后,我们将新分支合并到生产分支。
我们喜欢这种方法的是我们可以选择我们想要在当前周期将其推送到生产的更改,我们不必推送所有内容,而如果我们直接提交到生产分支,那么如果我们想要推送一个紧急更新然后我们必须立即推送所有内容。
我有两个问题:
由于
答案 0 :(得分:1)
最佳做法是祝福一个分支(通常为master
)作为生产准备 - “推动什么,什么不是”游戏是等待发生的灾难。当然,该分支无法接收未准备好推送的更改,因此保留未分支的分支是完全可以接受的。从主人(通过merge
或rebase
)更新之间的时间越长,您就越有可能发生冲突。
有一些方法可以构建代码/ css以最小化冲突(一致的格式化,逻辑文件结构等),但避免它们的最佳方法是通信。学好一个好的合并工具(我喜欢BeyondCompare)也有帮助。
答案 1 :(得分:1)
我看不出写得好,手动编码的js / css注定会导致冲突(自动生成的代码是另一个故事)。有时候会有一些冲突,但只要你不改变“一切,所有的时间”它应该是可管理的。当分支编辑文件的不同部分时,它们应自动合并。