I think any process you choose to use requires some flexibility.
If you use topic branches for each ticket you could choose not to merge any which are clearly incomplete back into your main branch at the end of that sprint. Unfortunately that discourages frequent merging and you're more likely to have significant merge conflicts as everyone tries to merge changes at the end of a sprint rather than as they finish which would give others a chance to rebase those changes into their history. You also need to then make sure to test the resulting merge of all of those features even if each feature seemed complete independently.
If you merge frequently then you can't easily select only those changes which pass review after the fact. You can however adopt a pattern from continuous deployment and build new features with the ability to enable and disable them in your releases. Code changes might be in the main branch but you don't necessarily have to expose new features until they are considered ready. Obviously this has some overhead and only makes sense for certain types of changes.
Finally you might try to avoid performing all of your review work at the end of a sprint. If you can get at least a pair of developers to go over a feature before merging it into your main branch and have decent tests in place you should be able to keep the quality of your main branch contributions high without adding too much of a bottleneck.
Hopefully you can find something that works for you.
I was thinking on creating a branch per ticket using GIT. And then merging only finished tickets/branches to one parent branch. any more ideas?
This approach although clean, would we a pain for maintenance and merging. And what if all tickets work fine on their own branch and don't when merged to the trunk?
My suggestions: 1. If creating separate branch per ticket, have the QA to integration testing. 2. If creating seperate branch per ticket, Make sure the Sprint User Stories are independent enough so that they don;t fail once merged.
Can you use svn? With svn every check in would create a tag of the source code. svn revert would revert changes for a particular check in related to a specific ticket. I am not sure if that is possible in GIT.
Try and keep a lag between your Sprints and the Releases. For eg. Sprints you are working on now, could be deployed 2 weeks later, so you have enough time to do the merging , reverting or planning around this.
发布评论
评论（2）
我认为您选择使用的任何流程都需要一定的灵活性。
如果您为每个工单使用主题分支，您可以选择在冲刺结束时不将任何明显不完整的分支合并回主分支。不幸的是，这阻碍了频繁的合并，并且您更有可能出现严重的合并冲突，因为每个人都试图在冲刺结束时合并更改，而不是在完成时合并，这将给其他人一个机会将这些更改重新设置为他们的历史记录。然后，您还需要确保测试所有这些功能的合并结果，即使每个功能看起来都是独立完成的。
如果您经常合并，那么您将无法轻松地仅选择那些事后通过审核的更改。但是，您可以采用持续部署的模式并构建新功能，并能够在您的版本中启用和禁用它们。代码更改可能位于主分支中，但您不一定必须公开新功能，直到它们被认为准备就绪。显然，这会产生一些开销，并且仅对某些类型的更改有意义。
最后，您可能会尝试避免在冲刺结束时执行所有审核工作。如果您可以让至少两名开发人员在将某个功能合并到您的主分支之前对其进行检查，并进行适当的测试，那么您应该能够保持主分支贡献的高质量，而不会增加太多的瓶颈。
希望您能找到适合您的东西。
I think any process you choose to use requires some flexibility.
If you use topic branches for each ticket you could choose not to merge any which are clearly incomplete back into your main branch at the end of that sprint. Unfortunately that discourages frequent merging and you're more likely to have significant merge conflicts as everyone tries to merge changes at the end of a sprint rather than as they finish which would give others a chance to rebase those changes into their history. You also need to then make sure to test the resulting merge of all of those features even if each feature seemed complete independently.
If you merge frequently then you can't easily select only those changes which pass review after the fact. You can however adopt a pattern from continuous deployment and build new features with the ability to enable and disable them in your releases. Code changes might be in the main branch but you don't necessarily have to expose new features until they are considered ready. Obviously this has some overhead and only makes sense for certain types of changes.
Finally you might try to avoid performing all of your review work at the end of a sprint. If you can get at least a pair of developers to go over a feature before merging it into your main branch and have decent tests in place you should be able to keep the quality of your main branch contributions high without adding too much of a bottleneck.
Hopefully you can find something that works for you.
这种方法虽然干净，但维护和合并会很痛苦。如果所有票证在自己的分支上都能正常工作，但在合并到主干时却不能正常工作，该怎么办？
我的建议：
1. 如果为每个工单创建单独的分支，请对集成测试进行 QA。
2. 如果为每个工单创建单独的分支，请确保 Sprint 用户故事足够独立，以便它们在合并后不会失败。
你可以使用svn吗？使用 svn，每次签入都会创建源代码的标签。 svn revert 将恢复与特定票证相关的特定签入的更改。我不确定这在 GIT 中是否可行。
尝试在 Sprint 和发布之间保持滞后。例如。您现在正在进行的 Sprint 可能会在 2 周后部署，因此您有足够的时间围绕此进行合并、恢复或规划。
This approach although clean, would we a pain for maintenance and merging. And what if all tickets work fine on their own branch and don't when merged to the trunk?
My suggestions:
1. If creating separate branch per ticket, have the QA to integration testing.
2. If creating seperate branch per ticket, Make sure the Sprint User Stories are independent enough so that they don;t fail once merged.
Can you use svn? With svn every check in would create a tag of the source code. svn revert would revert changes for a particular check in related to a specific ticket. I am not sure if that is possible in GIT.
Try and keep a lag between your Sprints and the Releases. For eg. Sprints you are working on now, could be deployed 2 weeks later, so you have enough time to do the merging , reverting or planning around this.