Depends on the team. If you're part of a technologically savvy team, then git is wonderful (and often more than wonderful). But if some people arn't comfortable on the command line, there could be some trouble (because tortoisegit is in its infancy and all the other GUIs I've come across, frankly, suck).
If you've got not-so-techie people to deal with (designers, higher-up managers, etc.), I'd go with something like subversion. TortoiseSVN is wonderful (and fairly easy to use), and svn's got maybe 80% of the awesome git has.
A much easier pitch (and one I've done successfully) is to set up a central Subversion repository, which gives everybody the good tools like TortoiseSVN. Then, developers who want to can use git-svn as a full Git environment as a Subversion client.
This works really well because there is still a central repository where everybody knows that a given change has either been committed, or it hasn't. Then, on the edges people can use the tools they want (Git) to get their jobs done.
We use git at my company, and based on your requirement for visual tools I would say no. tortoisegit is coming, but isn't quite there yet. Tools like GitX and GitNub are great in OS X, but they don't totally cover everything you're describing.
Give it time, though. Git is moving at a pretty quick pace, and thanks to that growth demand for visual tools is increasing.
The biggest issue you'll probably run into is the paradigm shift. It's not the easiest thing to master, and it will be frustrating to some on your team as they get used to working with Git and its more distributed (although I'm not a big fan of calling them distributed SCMs) nature.
With that said, using Git has been awesome and my company, and I'd love to see another company join the mix.
Moving from VSS to Subversion is going to be already a great upgrade. Subversion will give you great features like atomic commits, great GUI, integration with IDEs, great Windows experience, the concept of a changeset, reliable repository, etc. For a typical Windows based company with small/medium teams, I think subversion is a great tool.
If you are interested in a Distributed VCS, then you should be looking at git, hg, bzr. hg and bzr are ahead of git as far as Windows supports. However, there is a ported command line version of git for Windows (msysgit) which merges back changes to main git. Also the git community is growing fast and hence I expect that the Windows experience will improve.
Git supports a hybrid scenario where the server can be CVS / SVN and individual developers can use git-svn to work locally and manage local branches. This kind of setup gives the best of both worlds. However, git-svn is flaky on Windows due to a dependency on Perl SVN libraries. In this scenario, it is not as easy to use nice features of git like developers sharing branches, etc.
Given that your projects are not open source, I think Subversion is likely to provide all the features you need. Once Git is up to the Windows usability bar that you need, then you can import your SVN repos into Git.
Unless your company is heavy on branching and merging, I would go for SVN, otherwise, you will need to consider a DVCS closely.
I have been working on an open source project, the repository was stored in CVS, which then got migrated to SVN, and then to Git. Every step was a major upgrade. The major motivation for SVN to Git move was to make it easier for contributors to maintain their own branches, keep them up to date, push them to developers, and for developers to easily apply them with minimum effort.
When it comes to graphical tools for git, the only useful tool I've used so far is gitk (which visualizes the revision tree for you) and I've been using git for the past half year myself, As someone else here put it, TortoiseGit is still very early and has some kinks to work out.
At work we've been evaluating three different DVCS's (namely git, mercurial (hg) and bazaar) and had a full packed evening presenting them for the rest of the company. Mercurial received most positive response and there is a Tortoise variant of it.
I'd suggest you do the same thing. Find someone who can present some alternative to git (such as mercurial or bazaar) and do a presentation together on DVCS at your company. It is more important to tell your coworkers how awesome DVCS is rather than the boss because in the end they will be using it. So it's more educational if they have been exposed to such tools and get a taste of it for themselves.
When we presented it we also assumed people didn't do version control so we explained quickly basic concepts such as checkin-checkout vs. commit-merge and why people version control. Basically it was like Eric Sink's articles on version control but stripped down to bare essentials.
Since you're going from VSS (and I'm so sorry) you might want to have a look at SVN. However as I see it, the only difference between distributed and the centralized approach is the added complexity of sharing code through a peer-to-peer looking network.
The default git GUI for Windows is awful and tends to get stuck in rescan loops. I now use the command line client, which seems fine as long as you can deal with using vi for making your log entries. I just started using github, which is ok but has lousy navigation.
Personally, I use Subversion with Apache for almost everything I do. Subversion works great, is well-documented, is easy to set up and free.
比如说，在一家公司，提交需要 QA 分析或配置经理的批准和/或文档，或者需要将修订号与错误报告中的修订号进行协调，我会认为像 Git 这样的分布式控制确实没有意义，从某种意义上说，范式转变是没有道理的； 它还不能很好地适应现有的 CM 流程（社会问题）； 它不能与现有工具、第三方工具和其他工具很好地集成； 而且它对 Windows 的支持很差。
并不是说它不好；而是说它不好。 我很怀疑它是否适合大多数企业环境。 我期待其他一些回复以获取见解。
Do most companies of any typical size really need distributed source control?
Git works well for open source projects where people from all over the world are collaborating on a project at vastly different times, where the validity of check-ins is determined by merit and a web of trust.
At a company where, say, a commit requires QA analysis or a configuration manager's approval and/or documentation, or to reconcile a revision number with that in a bug report, I would submit that distributed control such as Git really does not make sense, in the sense that the paradigm shift is not warranted; that it does not yet fit well with existing CM processes (a social problem); that it does not integrate well with existing tools, third-party and otherwise; and that it has poor Windows support.
Not that it's not good; it's that I am quite skeptical to believe that it's the right tool for most corporate environments. I look forward to some of the other responses for insight.
I am a newcomer at GIT, and after using it for a a couple of weeks have to say that its really great, once you get the hang of the command line prompts.
To answer your question "Is Git ready?" => I think it is (except for the command line learning curve.)
I think you and your team/company should ask yourselves "Are you ready for git?." Once you start using it you will clearly have alot of power at your fingertips.
Just in follow-up to Spoike's mention of TortoiseHg for Mercurial, the windows standalone download for Bazaar does include TortoiseBzr these days, although it is marked as experimental.
I tried it quite a few versions ago and found it unstable, but it may have improved greatly since then (especially if they are willing to package it with the official Bazaar release).
If you're really after a decentralised version control with a tortoise like interface, I would give both a go and see how they fair.
When I was first exposed to Git, my first reaction was 'I just don't Git it'. I saw many powerful tools, but they weren't very intuitive. As I became used to using Git, I realized that the only feature that I really liked was quick cheap and easy branches.
I tried a few of the graphical front ends, including the GTK one that ships with Git. I found those to be more confusing than command line operations.
If your company is used to Subversion and you need to change to a DVCS, try Mercurial. Subversion users will feel at home very quickly. However, few people can really wrap their head around Mercurial's idea of what a branch should be .. which kind of shoots using a DVCS in the foot in the first place (barring being able to commit locally and push/pull to others prior to pushing to the main repository).
I work daily with Subversion and Mercurial, which suits all of my projects quite well. I think, unless you need Git's power of branching and ability to edit previous revisions ... Subversion or HG is going to be your best bet. I would not recommend Git as anyone's first exposure to a DVCS, but just my opinion and experience with it.
Is there support for Git within most 3rd party applications (other than Eclipse..) yet? Not for many of the ones I've seen.
Git is probably not going to be replacing SVN completely--they are different enough that each may have their role for some time. Anyway to answer the overall question: no, it's not ready for prime time in the business world. Perhaps it will be some day, in some cases (probably not all cases), but of course it's still too new--many people have not even heard of it yet! Just the fact that you've been advised to do a presentation on it to get buy-in should be a red flag. If you go to devs nowadays and say you want to move to SVN, the only ones who won't immediately understand are the ones living under a rock, and who cares about them?
Besides, newer is not always better. It takes time for this type of paradigm shift to be confirmed as an improvement--look at the backlash on Maven over time. Don't be so fast to jump ship from a proven solution, not when your job and reputation is at stake--if Git doesn't work out, you wouldn't look good recommending it. At least with a product like SVN you have the fact that it's NOT new, it's definitely proven over time, and even if there are problems the recommendation can't be questioned too harshly because it's still the default answer from most devs. It's harder attacking advice to switch to an industry standard than a switch to something new and non-standard.
Not the answer you wanted to hear (it appears you've already made your decision), but ask yourself if the benefits (and branches are something to be avoided, not encouraged) really outweigh the risks.
发布评论
评论（13）
取决于团队。 如果您是技术娴熟的团队的一员，那么 git 会很棒（而且通常更精彩）。 但如果有些人不习惯使用命令行，可能会遇到一些麻烦（因为 tortoisegit 还处于起步阶段，坦率地说，我遇到过的所有其他 GUI 都很糟糕）。
如果你要与不太技术的人打交道（设计师、高层管理人员等），我会选择颠覆之类的方法。 TortoiseSVN 非常棒（而且相当容易使用），而且 svn 可能拥有 80% 的 git 功能。
Depends on the team. If you're part of a technologically savvy team, then git is wonderful (and often more than wonderful). But if some people arn't comfortable on the command line, there could be some trouble (because tortoisegit is in its infancy and all the other GUIs I've come across, frankly, suck).
If you've got not-so-techie people to deal with (designers, higher-up managers, etc.), I'd go with something like subversion. TortoiseSVN is wonderful (and fairly easy to use), and svn's got maybe 80% of the awesome git has.
一个更简单的方法（我已经成功完成了）是建立一个中央 Subversion 存储库，它为每个人提供像 TortoiseSVN 这样的好工具。 然后，想要的开发人员可以使用 git-svn 作为完整的 Git 环境作为 Subversion 客户端。
这非常有效，因为仍然有一个中央存储库，每个人都知道给定的更改要么已提交，要么尚未提交。 然后，在边缘，人们可以使用他们想要的工具（Git）来完成他们的工作。
A much easier pitch (and one I've done successfully) is to set up a central Subversion repository, which gives everybody the good tools like TortoiseSVN. Then, developers who want to can use
git-svnas a full Git environment as a Subversion client.This works really well because there is still a central repository where everybody knows that a given change has either been committed, or it hasn't. Then, on the edges people can use the tools they want (Git) to get their jobs done.
我们在我的公司使用 git，根据您对可视化工具的要求，我会说不。 tortoisegit 即将到来，但尚未完全实现。 像 GitX 和 GitNub 这样的工具在 OS X 中非常有用，但它们并不能完全涵盖您所描述的所有内容。
不过，给点时间吧。 Git 正在以相当快的速度发展，并且由于这种增长，对可视化工具的需求也在增加。
您可能遇到的最大问题是范式转变。 这并不是最容易掌握的事情，而且对于团队中的一些人来说，这会让他们感到沮丧，因为他们习惯了使用 Git 及其更加分布式的特性（尽管我不太喜欢称它们为分布式 SCM）。
话虽如此，使用 Git 对我的公司来说非常棒，而且我很高兴看到另一家公司加入其中。
We use git at my company, and based on your requirement for visual tools I would say no. tortoisegit is coming, but isn't quite there yet. Tools like GitX and GitNub are great in OS X, but they don't totally cover everything you're describing.
Give it time, though. Git is moving at a pretty quick pace, and thanks to that growth demand for visual tools is increasing.
The biggest issue you'll probably run into is the paradigm shift. It's not the easiest thing to master, and it will be frustrating to some on your team as they get used to working with Git and its more distributed (although I'm not a big fan of calling them distributed SCMs) nature.
With that said, using Git has been awesome and my company, and I'd love to see another company join the mix.
从 VSS 迁移到 Subversion 已经是一个很大的升级。 Subversion 将为您提供出色的功能，如原子提交、出色的 GUI、与 IDE 集成、出色的 Windows 体验、变更集的概念、可靠的存储库等。对于拥有中小型团队的典型基于 Windows 的公司，我认为 Subversion 是一个很棒的功能工具。
如果您对分布式 VCS 感兴趣，那么您应该查看 git、hg、bzr。 就 Windows 支持而言，hg 和 bzr 领先于 git。 但是，有一个适用于 Windows 的 git 移植命令行版本 (msysgit)，它将更改合并回主 git。 此外，git 社区正在快速发展，因此我预计 Windows 体验将会得到改善。
Git支持混合场景，服务器可以是CVS/SVN，个人开发者可以使用git-svn在本地工作并管理本地分支。 这种设置提供了两全其美的效果。 然而，由于对 Perl SVN 库的依赖，git-svn 在 Windows 上不稳定。 在这种情况下，使用 git 的优秀功能（例如开发人员共享分支等）并不那么容易。
鉴于您的项目不是开源的，我认为 Subversion 很可能会提供您需要的所有功能。 一旦 Git 达到您需要的 Windows 可用性标准，您就可以将 SVN 存储库导入到 Git 中。
除非你的公司非常注重分支和合并，否则我会选择 SVN，否则，你将需要仔细考虑 DVCS。
我一直在做一个开源项目，存储库存储在CVS中，然后迁移到SVN，然后迁移到Git。 每一步都是重大升级。 SVN 迁移到 Git 的主要动机是让贡献者更轻松地维护自己的分支、使其保持最新、将其推送给开发人员，并让开发人员能够以最小的努力轻松应用它们。
Moving from VSS to Subversion is going to be already a great upgrade. Subversion will give you great features like atomic commits, great GUI, integration with IDEs, great Windows experience, the concept of a changeset, reliable repository, etc. For a typical Windows based company with small/medium teams, I think subversion is a great tool.
If you are interested in a Distributed VCS, then you should be looking at git, hg, bzr. hg and bzr are ahead of git as far as Windows supports. However, there is a ported command line version of git for Windows (msysgit) which merges back changes to main git. Also the git community is growing fast and hence I expect that the Windows experience will improve.
Git supports a hybrid scenario where the server can be CVS / SVN and individual developers can use git-svn to work locally and manage local branches. This kind of setup gives the best of both worlds. However, git-svn is flaky on Windows due to a dependency on Perl SVN libraries. In this scenario, it is not as easy to use nice features of git like developers sharing branches, etc.
Given that your projects are not open source, I think Subversion is likely to provide all the features you need. Once Git is up to the Windows usability bar that you need, then you can import your SVN repos into Git.
Unless your company is heavy on branching and merging, I would go for SVN, otherwise, you will need to consider a DVCS closely.
I have been working on an open source project, the repository was stored in CVS, which then got migrated to SVN, and then to Git. Every step was a major upgrade. The major motivation for SVN to Git move was to make it easier for contributors to maintain their own branches, keep them up to date, push them to developers, and for developers to easily apply them with minimum effort.
当谈到 git 的图形工具时，迄今为止我使用过的唯一有用的工具是 gitk（它为您可视化修订树）并且我自己在过去的半年里一直在使用 git，正如这里其他人所说的，TortoiseGit 还处于早期阶段，还有一些问题需要解决。
在工作中，我们一直在评估三种不同的 DVCS（即 git、mercurial (hg) 和bazaar），并度过了一个充实的夜晚，向公司其他成员展示了它们。 Mercurial 收到了最积极的回应，并且有一个 Tortoise 变体。
我建议你也做同样的事情。 找到能够提供 git 替代方案（例如 Mercurial 或 bazaar）的人，并在您的公司一起就 DVCS 进行演示。 告诉你的同事 DVCS 有多棒比告诉老板更重要，因为最终他们会使用它。 因此，如果他们接触过这些工具并亲自尝试一下，那就更有教育意义了。
当我们提出它时，我们还假设人们没有进行版本控制，因此我们快速解释了基本概念，例如签入-签出与提交-合并以及为什么人们版本控制。 基本上它就像Eric Sink 关于版本控制的文章，但精简到最基本的内容。
由于您要从 VSS 出发（我很抱歉），您可能想看看 SVN。 然而，在我看来，分布式和集中式方法之间的唯一区别是通过点对点网络共享代码增加了复杂性。
When it comes to graphical tools for git, the only useful tool I've used so far is gitk (which visualizes the revision tree for you) and I've been using git for the past half year myself, As someone else here put it, TortoiseGit is still very early and has some kinks to work out.
At work we've been evaluating three different DVCS's (namely git, mercurial (hg) and bazaar) and had a full packed evening presenting them for the rest of the company. Mercurial received most positive response and there is a Tortoise variant of it.
I'd suggest you do the same thing. Find someone who can present some alternative to git (such as mercurial or bazaar) and do a presentation together on DVCS at your company. It is more important to tell your coworkers how awesome DVCS is rather than the boss because in the end they will be using it. So it's more educational if they have been exposed to such tools and get a taste of it for themselves.
When we presented it we also assumed people didn't do version control so we explained quickly basic concepts such as checkin-checkout vs. commit-merge and why people version control. Basically it was like Eric Sink's articles on version control but stripped down to bare essentials.
Since you're going from VSS (and I'm so sorry) you might want to have a look at SVN. However as I see it, the only difference between distributed and the centralized approach is the added complexity of sharing code through a peer-to-peer looking network.
Windows 的默认 git GUI 很糟糕，并且往往会陷入重新扫描循环。 我现在使用命令行客户端，只要您可以使用 vi 来创建日志条目，这似乎就很好。 我刚刚开始使用 github，它还可以，但导航很糟糕。
就我个人而言，我所做的几乎所有事情都使用 Subversion 和 Apache。 Subversion 效果很好，文档齐全，易于设置并且免费。
The default git GUI for Windows is awful and tends to get stuck in rescan loops. I now use the command line client, which seems fine as long as you can deal with using vi for making your log entries. I just started using github, which is ok but has lousy navigation.
Personally, I use Subversion with Apache for almost everything I do. Subversion works great, is well-documented, is easy to set up and free.
大多数任何典型规模的公司真的需要分布式源代码控制吗？
Git 非常适合开源项目，在这些项目中，来自世界各地的人们在截然不同的时间就一个项目进行协作，签入的有效性由优点和信任网络决定。
比如说，在一家公司，提交需要 QA 分析或配置经理的批准和/或文档，或者需要将修订号与错误报告中的修订号进行协调，我会认为像 Git 这样的分布式控制确实没有意义，从某种意义上说，范式转变是没有道理的； 它还不能很好地适应现有的 CM 流程（社会问题）； 它不能与现有工具、第三方工具和其他工具很好地集成； 而且它对 Windows 的支持很差。
并不是说它不好；而是说它不好。 我很怀疑它是否适合大多数企业环境。 我期待其他一些回复以获取见解。
Do most companies of any typical size really need distributed source control?
Git works well for open source projects where people from all over the world are collaborating on a project at vastly different times, where the validity of check-ins is determined by merit and a web of trust.
At a company where, say, a commit requires QA analysis or a configuration manager's approval and/or documentation, or to reconcile a revision number with that in a bug report, I would submit that distributed control such as Git really does not make sense, in the sense that the paradigm shift is not warranted; that it does not yet fit well with existing CM processes (a social problem); that it does not integrate well with existing tools, third-party and otherwise; and that it has poor Windows support.
Not that it's not good; it's that I am quite skeptical to believe that it's the right tool for most corporate environments. I look forward to some of the other responses for insight.
我是 GIT 的新手，在使用了几周之后，一旦掌握了命令行提示的窍门，我不得不说它真的很棒。
回答你的问题“Git 准备好了吗？” => 我认为是的（除了命令行学习曲线。）
我认为你和你的团队/公司应该问自己“你准备好使用 git 了吗？” 一旦您开始使用它，您将明显拥有触手可及的强大力量。
学习 git 的第一步是：
I am a newcomer at GIT, and after using it for a a couple of weeks have to say that its really great, once you get the hang of the command line prompts.
To answer your question "Is Git ready?" => I think it is (except for the command line learning curve.)
I think you and your team/company should ask yourselves "Are you ready for git?." Once you start using it you will clearly have alot of power at your fingertips.
Your first steps to learning git are:
紧接着 Spoike 提到了 Mercurial 的 TortoiseHg，Bazaar 的 Windows 独立下载现在确实包含了 TortoiseBzr，尽管它被标记为实验性的。
我之前尝试过几个版本，发现它不稳定，但从那时起它可能已经有了很大的改进（特别是如果他们愿意将其与官方 Bazaar 版本打包）。
如果你真的想要一个像乌龟一样界面的去中心化版本控制，我会尝试一下，看看它们是否公平。
E.
Just in follow-up to Spoike's mention of TortoiseHg for Mercurial, the windows standalone download for Bazaar does include TortoiseBzr these days, although it is marked as experimental.
I tried it quite a few versions ago and found it unstable, but it may have improved greatly since then (especially if they are willing to package it with the official Bazaar release).
If you're really after a decentralised version control with a tortoise like interface, I would give both a go and see how they fair.
E.
当我第一次接触 Git 时，我的第一反应是“我只是不使用 Git”。 我看到了很多强大的工具，但它们不是很直观。 当我习惯使用 Git 后，我意识到我真正喜欢的唯一功能是快速、廉价且简单的分支。
我尝试了一些图形前端，包括 Git 附带的 GTK 前端。 我发现这些比命令行操作更令人困惑。
如果您的公司已经习惯了 Subversion，并且您需要更改为 DVCS，请尝试 Mercurial。 Subversion 用户很快就会有宾至如归的感觉。 然而，很少有人能够真正理解 Mercurial 的分支应该是什么的想法..首先使用 DVCS 进行哪种射击（除非能够在本地提交并在推送之前推送/拉动给其他人）到主存储库）。
我每天都使用 Subversion 和 Mercurial，它们非常适合我的所有项目。 我认为，除非你需要 Git 的分支能力和编辑以前版本的能力……Subversion 或 HG 将是你最好的选择。 我不会推荐 Git 作为任何人第一次接触 DVCS 的方式，而只是推荐我对它的看法和经验。
When I was first exposed to Git, my first reaction was 'I just don't Git it'. I saw many powerful tools, but they weren't very intuitive. As I became used to using Git, I realized that the only feature that I really liked was quick cheap and easy branches.
I tried a few of the graphical front ends, including the GTK one that ships with Git. I found those to be more confusing than command line operations.
If your company is used to Subversion and you need to change to a DVCS, try Mercurial. Subversion users will feel at home very quickly. However, few people can really wrap their head around Mercurial's idea of what a branch should be .. which kind of shoots using a DVCS in the foot in the first place (barring being able to commit locally and push/pull to others prior to pushing to the main repository).
I work daily with Subversion and Mercurial, which suits all of my projects quite well. I think, unless you need Git's power of branching and ability to edit previous revisions ... Subversion or HG is going to be your best bet. I would not recommend Git as anyone's first exposure to a DVCS, but just my opinion and experience with it.
有一个关于 GIT 的非常好的播客。
There is a very good pod cast about GIT.
当然，我认为 Git 已经准备好了。 只要确保您的项目计划中有时间让人们在切换时适应它......
Sure, I think Git is ready. Just make sure that you have time in your project schedule to get people used to it when they switch over...
大多数第 3 方应用程序（Eclipse 除外……）是否支持 Git？ 对于我见过的许多人来说并非如此。
Git 可能不会完全取代 SVN——它们有足够的不同，以至于每个都可能在一段时间内发挥自己的作用。 无论如何，回答总体问题：不，它还没有准备好迎接商业世界的黄金时段。 也许有一天，在某些情况下（可能不是所有情况），但当然它仍然太新了——很多人甚至还没有听说过它！ 事实上，你被建议做一个演示以获得认可，这应该是一个危险信号。 如果你现在去找开发人员说你想迁移到 SVN，唯一不会立即理解的是那些生活在岩石下的人，谁关心他们呢？
此外，更新并不总是更好。 这种类型的范式转变需要时间才能被确认为一种改进——看看随着时间的推移对 Maven 的强烈反对。 不要那么快地放弃一个经过验证的解决方案，除非你的工作和声誉受到威胁——如果 Git 不起作用，那么你推荐它就显得不太好。 至少对于像 SVN 这样的产品，你知道它不是新产品，它肯定已经随着时间的推移而得到证明，即使存在问题，也不能对建议提出太严厉的质疑，因为它仍然是默认答案来自大多数开发者。 攻击转向行业标准的建议比转向新的和非标准的东西更难。
这不是您想听到的答案（看来您已经做出了决定），而是问问自己，好处（以及分支是应该避免而不是鼓励的东西）是否真的大于风险。
Is there support for Git within most 3rd party applications (other than Eclipse..) yet? Not for many of the ones I've seen.
Git is probably not going to be replacing SVN completely--they are different enough that each may have their role for some time. Anyway to answer the overall question: no, it's not ready for prime time in the business world. Perhaps it will be some day, in some cases (probably not all cases), but of course it's still too new--many people have not even heard of it yet! Just the fact that you've been advised to do a presentation on it to get buy-in should be a red flag. If you go to devs nowadays and say you want to move to SVN, the only ones who won't immediately understand are the ones living under a rock, and who cares about them?
Besides, newer is not always better. It takes time for this type of paradigm shift to be confirmed as an improvement--look at the backlash on Maven over time. Don't be so fast to jump ship from a proven solution, not when your job and reputation is at stake--if Git doesn't work out, you wouldn't look good recommending it. At least with a product like SVN you have the fact that it's NOT new, it's definitely proven over time, and even if there are problems the recommendation can't be questioned too harshly because it's still the default answer from most devs. It's harder attacking advice to switch to an industry standard than a switch to something new and non-standard.
Not the answer you wanted to hear (it appears you've already made your decision), but ask yourself if the benefits (and branches are something to be avoided, not encouraged) really outweigh the risks.