0

我们使用 git 作为版本控制，我们使用它的方式如下：

我们的主要分支是生产每个新问题或升级开发人员应该从生产分支创建新分支，更新代码并对其进行测试，然后将他的更改提交到新分支。之后，我们将新分支合并到生产分支。

我们喜欢这种方法的地方在于，我们可以选择我们想要在当前周期将其推送到生产的更改，我们不必推送所有内容，而如果我们直接提交到生产分支，那么如果我们想要推送一个紧急的更新然后我们必须立即推送所有内容。

我对此有两个问题：

  1. 这是使用 git 的最佳实践吗？还是有更好的方法？
  2. 我们面临 js 和 css 文件的问题，因为这些文件可能会在每个新分支中更新，所以有时我们在两个不同的工单中编辑这些文件，当我们将其合并到生产环境时，我们将不得不修复一长串冲突，很多时候我们最终删除了一些我们仍然需要的代码，或者它是新更改的一部分。我们能做些什么来克服这个问题吗？

谢谢

4

2 回答 2

1

总的来说，这听起来很合理。我不是说你应该完全按照那里的描述去做，但为了获得一些灵感，请阅读： http: //nvie.com/posts/a-successful-git-branching-model/

我看不出编写良好、手动编码的 js/css 注定会导致冲突（自动生成的代码是另一回事）。有时会有一些冲突，但只要你不改变“一切，一直”，它应该是可以管理的。当分支编辑文件的不同部分时，它们应该会自动合并。

于 2013-07-16T06:08:39.223 回答
1

将一个分支（通常master）祝福为生产就绪是一种最佳实践——“什么被推动，什么不是”游戏是一场等待发生的灾难。自然，该分支无法接收尚未准备好推送的更改，因此不合并分支是完全可以接受的。来自 master 的更新之间的时间越长（通过merge或rebase），您就越有可能发生冲突。

有一些方法可以构建代码/css 以最大限度地减少冲突（一致的格式、逻辑文件结构等），但避免它们的最佳方法是通信。好好学习一个好的合并工具（我喜欢 BeyondCompare）也有帮助。

于 2013-07-16T03:00:37.660 回答