自从我从svn切换到git后,我每次重新编译时都开始做更多的提交,我的测试通过了我的工作.最后我最终按功能提交功能.
我还使用像emacs,wordpress等git跟踪一些其他项目.我看到他们不经常提交.所以我想知道你怎么承诺？
我找不到任何使用git管理版本的"正确"方法.说,我有master,release-1,release-2和release-3分支.版本1已经发布,我只对其进行了错误修正和发布版本标记.第2版将很快发布,我主要在这个分支上发展,而在3年我开发了将来需要的东西.
当我在release-2上添加一些功能时,它也应该转到3,但不是1,我应该:
当我需要在所有版本中进行更改时,我是否应该在master上进行更改并将其挑选到所有分支中？
我是否应该掌握最新的(第3版分支)或者第3版的开发人员,并在我需要发布4分支之前合并到主服务器？
当我在发行版1或版本2上修复时,我应该合并或者选择它来掌握或者说它？
我不太确定我什么时候应该挑选,什么时候应该合并,如果分支之间的代码流正确的话.
我有一个我从git存储库管理的项目.我们使用progit分支策略(如接受的答案中所述,这里:小开发团队的Git分支策略),其中一个分支是生产分支,另一个分支是开发/测试分支.我们使用fabric部署代码.
当我们准备使用git创建新的生产版本时,我们将开发/测试分支合并到生产分支中,然后使用结构部署生产分支.问题是开发和生产之间存在代码差异 - 一些徽标更改,一些不同的数据库主机/凭据等等.我一直在保存包含差异的.patch文件,并且在部署生产环境时使用结构应用补丁,但这不能很好地工作.特别是,如果补丁周围的某些代码发生了变化,它将完全失败 - 补丁无法应用,我的部署将中止.
我一直在想我是否应该直接将所有更改应用到生产分支？这有什么缺点？
我关心的一个特殊用例是我们是否需要制作修补程序.我们目前通过从生产环境分支,进行更改,然后将该分支合并回开发和生产来实现这一目标.如果生产分支与开发分支不同,那么当修补程序合并到开发中时,这些更改是否会被拉入开发分支？
所以我正在从 Github 找出最简单的分支/部署策略，它至少有一个 dev 和一个 release(master) 分支。看到这个答案后，我认为这非常接近我们所需要的。除了只能部署某些功能的一个大问题。不是一切。
此处提供的 2 个选项还不够好。这是一个常见的场景，每次恢复都是很讨厌的。另外，我读过樱桃采摘还有其他问题，特别是因为樱桃采摘的提交实际上是副本（这是真的吗？）
现在，我在想，如果对于我们开始处理的新功能，我们创建一个分支，并将它们合并到我们选择的 dev 分支，我们可以将这些分支合并到 release 分支（而不是从 dev 合并到 release 分支，我们从功能分支合并到开发和发布，这样我们就可以选择要发布的内容），这样我们就可以只准备发布所需的更改。我至少可以想到两个可能的问题：
所以，总而言之，我如何保留一个开发分支，在那里进行一些更改，然后只将一些内容移动到另一个分支？。
非常感谢。