按功能划分 - 优点/缺点？
我目前正在从事一个项目，其中分支和合并从一开始就运行得不太好。为了改变这一点，我们一直在讨论多种不同的方法。我想每个人对于如何做这类事情都有自己的哲学，所以它似乎也在这里。
我们一直在讨论的一件事是按功能进行分支。对于这种特殊方法的好坏，我们碰巧有不同的看法。
您以前有这样做的经验吗？效果好吗？您是否遇到过问题 - 什么样的问题？
我知道这个问题并没有真正的正确答案，但我发现听到世界各地其他开发人员的意见非常有趣，而 stackowerflow 似乎是一个很好的地方。
I'm currently working in a project where branching and merging haven't been working very well at all from the start. In order to change this, we've been talking about loads of different ways to do it. I assume everyone have there own philosophy about how to do this kind of stuff, and so it seems to be here as well.
One thing we've been talking about is to branching by feature. We happen to have very different views at whats good and bad with this particular method.
Do you have experience of doing this before? Did it work well? Did you have issues - what kind of issues?
I know this question wont really have a correct answer, but I find it very interesting to hear the opinions of other developers around the world, and stackowerflow seems to be a great spot for that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们使用按功能分支，它对我们来说非常有效。最大的优势是，功能团队知道他们正在做的事情不会影响其他功能团队，直到新功能被集成（在我们的例子中集成到 Main 中）。
当我们完成新功能（并且分支已合并到主分支）时，我们将分支移动到分支历史文件夹中。这使得开发人员需要查看的分支（文件夹）数量保持在最低限度。
在我们的例子中，没有人在主分支工作。所有开发都在功能分支中完成。初始开发（在第一次发布到生产之前）是在开发分支中完成的。第一次发布到生产环境后，所有开发都在新的功能分支中完成。
We use branch by feature and it works very well for us. The biggest advantage is that the feature teams know that what they are working on does not affect the other feature teams until the new feature is integrated (into Main in our case).
When we are finished with a new feature (and the branch has been merged to Main) we move the branch into a Branch History folder. This keeps the numebr of branches (folders) the developers need to look at to a minumum.
In our case, no one works in the Main branch. All development is done in a feature branch. Initial development (before the first release to Production) is done in a development branch. After the first realease to Production all development is done in a new Feature Branch.
如果您有一个中小型团队，那么当您并不真正需要完全分支隔离时，请避免额外的分支……特别是如果您的开发团队的文化不利于正确分支和合并。也许作为维护更少分支的交换，请确保所有被允许进行合并的开发人员都虔诚地遵循合并实践。搁置集（在 TFS 中）和短期功能分支是最小化合并开销和相关风险的好技术。
详细信息
以下是我发现的一种平衡生产力与版本控制安全性的模式（适用于约 25 名开发人员和约 3 名测试人员的团队）：
在同一分支中工作：开发人员从事松散耦合或不相关的工作代码可以相对安全地直接在同一个开发（或“集成”）分支中工作。错误修复和非破坏性更改非常适合这里（降低影响其他开发人员的重大回归的风险）。持续集成构建和门控构建是降低许多开发人员在同一分支工作的风险的两种最佳实践。
切换注意：功能切换可用于进一步避免分支的需要，但要确保测试/维护切换行为的开销不会比使用分支风险更大。
搁置集：使用版本控制系统的功能来保存开发人员特定的原型分支中待处理的更改。如果签入 TFS (Team Foundation Server) 的开发人员是唯一需要在签入集成/开发分支之前开发和测试功能的开发人员，则可以使用搁置集而不是个人分支（或许多微功能/任务分支） 。我相信其他版本控制系统也有类似的结构
ANTIPATTERN：本地工作区自动为每个开发人员提供临时隔离...但开发人员需要经常/每天在源代码管理中的某个位置检查其更改，以防止丢失数天以上的本地工作的风险.)
短期分支：当您确实需要一个分支进行隔离时（例如需要多个开发人员共同处理的破坏性功能），那么创建短期功能分支是一个不错的选择要走的路。我建议采用一种分支命名约定，使分支的使用随着时间的推移保持良好的定义和唯一性
上述工作流程的主要优点是它最大限度地减少了合并税（前向/反向集成（向下/向上合并）所花费的时间），而不是开发直接提高客户满意度的功能。
示例场景：新的“酷”功能将破坏现有功能并构建直至完成。它还需要 2 个以上的开发人员在同一代码库上进行协作（消除使用 Shelveset 的选项）。 “Cool”的开发所有者创建名为 Cool1 的分支，然后开发并创建分支。集成测试功能的第一个版本。开发所有者负责每天（最多每周一次）合并父级更改。
确认准备好合并（父级合并做子级 (FI)，所有 UT 和核心验收测试都运行并且仍然通过）。合并到父级 (RI)，然后确认父级分支中的工作（所有 UT 和核心验收测试均通过），然后删除 Cool1 功能分支（清理）。
合并到开发/集成分支后更彻底地测试 Cool 功能。 （测试资源有限，因此避免每个分支都有完整的测试环境。）Cool 的错误修复和战术增强/重构将直接在 Dev 分支中完成（当分配的开发人员在签入之前需要很多天进行本地开发/测试时，使用搁置集）。如果稍后需要对 Cool 进行重大（多开发人员）返工，则创建一个新的 Cool2 分支。
TFS2010 移动/重命名 注意： TFS 2010 移动和重命名行为已更改（从 TFS 2008 开始）以进行移动和重命名 =“分支到新名称/位置，然后将原始项目标记为已删除”。这意味着如果您不想在源代码管理 \Dev\ 中看到不活动的功能分支，则应该删除它们，而不是将分支移动到其他文件夹。这也意味着启用查看已删除文件夹的开发人员将始终将这些已删除（或移动或重命名）的短期分支视为“幽灵”，可能会变得混乱。 （这就是您查看历史记录或取消删除已删除项目的方式。）
If you have a small-medium team then avoid extra branches when you don't truly need full branch isolation... especially if your dev team's culture is averse to branching and merging properly. Perhaps in exchange for fewer branches to maintain make sure merging practices are followed religiously by all developers who are allowed to do merges. Shelvesets (in TFS) and short-lived feature branches are good techniques to minimize merge overhead and related risks.
DETAILS
Here's a pattern I've found to balance productivity with version control safety (for team of ~25 devs and ~3 testers):
Work in same branch: Developers working on loosly coupled or unrelated code can work directly in the same Dev (or "Integration") branch relatively safely. Bugfixes and non-breaking changes nicely fit here (lower risk of major regressions impacting other devs). Continuous Integration builds and gated builds are two best practices that mitigate risk of many devs working in the same branch.
Toggle Note: Feature toggles can be used to further avoid need to branch, but make sure overhead to test/maintain the toggle behavior isn't riskier than using a branch.
Shelvesets: Use your version control system's feature to save pending changes in developer-specific proto-branches. Developers checking in to TFS (Team Foundation Server) can use shelvesets instead of personal branches (or many micro-feature/task branches) if they are the only one who needs to develop and test the feature before checking in to the integration/dev branch. I believe other version control systems have similar constructs
ANTIPATTERN: Local workspace(s) automatically provide temporary isolation for each developer... but developers need to check in their changes frequently/daily somewhere in source control to prevent risk of losing days+ of local-only work.)
Short-lived branches: When you do need a branch for isolation (such as for a breaking feature that multiple developers need to work on) then creating short-lived feature branches is one good way to go. I recommend a branch naming convention that keeps branch use well defined and unique over time.
The primary advantage of the above workflow is that it minimizes the merge tax (time spent Integrating forward/reverse (merging down/up)) instead of developing features that directly improve customer happiness.
Example Scenario: The new "Cool" feature will break existing functionality and builds until completed. It also requires 2+ devs to collaborate on same codebase (eliminating option to use Shelveset). Dev owner for "Cool" Creates branch named Cool1, then develop & integration test the first version of feature. Dev owner is responsible for merging parent changes daily (weekly at absolute most).
Confirm ready to merge (Parent merged do child (FI), all UT and core Acceptance Tests run and still pass). Merge to parent (RI), then confirm works in parent branch (all UT and core Acceptance Tests pass), then delete the Cool1 feature branch (cleanup).
Test the Cool feature more thoroughly after merged to dev/integration branch. (Test resources are limited so avoid full test environment for each branch.) Bugfixes and tactical enhancements/refactoring for Cool would are done directly in the Dev branch (using shelvesets when assigned dev needs many days to localy dev/test before checkin). If major (multi-developer) rework of Cool is needed later then create a new Cool2 branch.
TFS2010 move/rename Note: TFS 2010 move and rename behavior changed (from TFS 2008) to make moves and Renames = "branch to new name/location, then mark original item as deleted". This means you should just delete the inactive feature branches if you don't want to see them in source control \Dev\ instead of moving the branch to a different folder. This also means developers that enable viewing deleted folders will always see these deleted (or moved or renamed) short-lived branches as "ghosts" which can get cluttered. (That's how you can view history or undelete a deleted item.)
功能分支的替代方案是功能切换（即代码中可以使功能可用或不可用的开关）。它们在这方面确实很有用。它们可以允许开发和部署新功能，但只有在切换......良好切换（甚至是一个词）时才可用。我想这就像整个谷歌实验室的想法。
这里需要注意的一点是，如果在开发过程中没有仔细考虑和测试，这些切换本身也可能导致戏剧性的后果。您实际上增加了需要执行的测试量，以了解启用和禁用功能时情况如何。如果您正在开发多个功能，那么您需要了解它们如何与启用/禁用状态的各种组合进行交互。
话虽如此，如果做得好，它们也会带来巨大的好处。您可以向某些用户（高级用户或该功能的拥护者等）发布功能，而不影响所有人。如果它被认为引起问题，则可以通过更改数据库记录中某些配置元素的存在来将其关闭。
一旦给定的功能被认为已通过测试，建议删除切换开关并使其成为整个应用程序的一部分。
话虽如此，我不认为功能分支不好，但它确实依赖于每个人都理解源代码控制和合并的概念，并确保分支不会与主分支过于脱节，从而导致一种巨大的 OMG 类型合并。
我最近参加了 Thoughtworks 主办的一次会议，马丁·福勒 (Martin Fowler) 讨论了这个主题。演讲的重点是持续交付以及这如何帮助克服缓慢且有风险的部署。请参阅http://www.thoughtworks.com/events/thoughtworks-continuous-delivery- devops 或搜索持续交付以获取更多信息。
An alternative to branches for features would be feature toggles (ie a switch in the code that can make a feature available or not). They can be really useful in this regard. They can allow new features to be developed and deployed, but only available once the toggle is...well toggled (is that even a word). I imagine it is something like the whole google labs idea.
The point to note here, is that these toggles can also cause dramas in themselves if they aren't carefully considered and tested during development. You are in effect increasing the amount of testing you need to perform to see how things behave with a feature enabled and disabled. If you have multiple features under development, then you need to see how they all interact with various combinations of enabled/disabled states.
Having said that, if done well, they offer great benefits too. You can release a feature to certain users (power users, or champions of the feature etc) without affecting everyone. If it is deemed to be causing problems, it could be turned off via a change in DB record of presence of some configuration element.
Once a given feature is deemed to have passed muster, it is advisable to remove the toggle and just make it part of the overall application.
Having said that, I don't think that feature branching is bad, but it does rely on everyone understanding the concept of source control and merging and ensuring that branches don't get too out of line with the main branch causing one massive OMG type merge.
I recently attended a conference hosted by Thoughtworks where Martin Fowler discussed this very topic. The talk was focused on Continuous Delivery and how this can help overcome slow and risky deployments. See http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops or just do a search for continious delivery for more info.
越多的团队在自己的分支上致力于合并目标，您的沟通就需要更好地处理冲突。
警惕代码中的高变动、耦合和公共区域。这些将是争论的领域。
按功能进行分支可以在 TFS 中有效完成，但与开发中的任何内容一样，越复杂，产生的开销就越大。
The more teams working on the merge target with their own branches the better your communication will need to be to deal with conflicts.
Be wary of high churn, coupled, and common areas in your code. Those will be the areas of contention.
Branch by feature can be done effectively in TFS, but as with anything in dev the more complex you get the more overhead you incur.
Git 比 TFS 好得多。我使用 git 已有 7 年多了，在此之前还使用过 TFS。最近我换了工作，必须使用TFS。仅拥有一个开发分支并且所有开发人员在同一开发上工作并不允许任何适当的审查机会。我喜欢这样一个事实：在 git 中，代码审查是一个正式的过程。
使用 git，我通过创建与功能/工作项相关的分支来在本地分支上工作。完成工作后，您可以将其推送到远程分支。然后，您将从远程分支向您的开发/集成分支发出拉取请求。一旦拉取请求被审核，审核者就会将 PR 合并到 dev 分支。这对我来说非常有效。
Git is way better then TFS. I have been using git for over 7 years now and used TFS before that. Recently I changed my job where I have to use TFS. Just having a dev branch and all developers working on the same dev does not allow any proper review opportunity. I love the fact that in git code review is a formal process.
With git i have worked on local branch by creating feature/workitem related branches. After you have with your work you can then push it to your remote branch. From the remote branch then you will do a pull request to your dev/integration branch. Once the pull request is reviewed then reviewer will merge the PR to dev branch. This has worked for me very nicely.