branching

我在项目中使用 Git 作为版本控制工具，并且经常遵循以下策略。 这个策略受到了A successful Git branching model的启发。 我有两个永久分支：master和develop。 以下是我日常开发中遵循的规则： 当我接手一个新任务或决定加入一个功能时，有两条主要路径： 如果功能较为简单，或后续提交不会破坏代码（至少我希望如此）：我可以在develop分支上提交，或者创建一个快速功能分支，然后将其合并到develop分支上。 如果功能需要进行多次提交才能完成，可能需要花费几天时间提交才能使功能恢复稳定的状态：我会创建一个功能分支，然后将其合并到develop分支上。 如果我们的生产服务器需要立即采取措施，比如需要尽快解决的 bug 修复，我会创建一个短期修复分支，解决问题后在本地和测试机上进行测试，然后将其合并到 master 和 develop 分支上。 如果我需要在生产服务器上快速推送一个功能或修改，并且 develop 分支中代码不稳定，我希望尽快得到该功能或修改：我可以跳过 develop 分支，创建一个快速功能分支并将其合并到 master 和 develop 分支上，只要这个功能或修改是快速且简单的。如果在后续过程中发现这是一个更复杂的问题，最好等待并稳定 develop 分支上的代码。 develop 分支会一直处于不稳定状态，所以在准备发布时，需要将其放入“冻结”状态。代码经过测试，所有工作流程都经过验证，准备将其合并到 master 分支上。 每次将 develop 或其他短期修复分支合并到 master 分支时，我都会使用版本号做标签，这样如果出现问题可以轻松回滚到先前的状态。