23

在我读到关于 Mercurial 和 Git 的任何地方，它们通常都会写一两行，这意味着 Git 在 Windows 上的能力有限（因为某些 Shell 脚本无法移植等），但我从未遇到过明确提及它们的页面。而且大多数页面都有点旧。

就功能而言，Windows 上的 Git 有哪些限制？并且必须在 Windows 上的 MinGW 和 MSYS 上运行 Git 是否有性能限制？

4

3 回答 3

27

编辑：所以它是 2016 年，距我在下面写下原始答案已有六年了。几年来我一直大量使用 git 和 mercurial，而且我也已经在 mac 上开发了几年。我已经非常熟悉和熟悉命令行中的 git 用法，但对于日常工作，我使用 Atlassian 的 SourceTree。这不是广告，只是更新此答案的说明。SourceTree 是一个双重抽象：对于 git/hg 相同的 ui，对于 Windows/Mac 相同的 ui。当您必须经常切换平台和项目时，这变得非常有吸引力。

在编写了在 Windows 上为 Git 设置客户端和服务器的指南之后，我对人们可以期待什么有了一个很好的了解。此外，我的主存储库（.git文件夹）大约有 260MB 的源代码，因此对于 Windows 上的日常 Git 工作来说，这确实不是一项微不足道的性能测试。

我的总体印象是，Windows 上的 Git 对于可能遇到的绝大多数情况都非常快，但有一个非常大的例外：git gui blame -C -C. 默认情况下，git 不会将责任归咎于文件重命名边界之外的文件，并且-C -C必须传递额外的参数才能实现这一点，但是事情真的会变慢。在现代硬件上需要 17 分钟才能为我们较大的约 20 kloc 源文件之一生成完整的注释。这种延迟真的会破坏你的注意力。

关于cygwin：

我只试过一次，没有任何意义。我真的想要一个本地解决方案。众所周知，cygwin 上的 git 运行良好。

关于TortoiseGit

Frank Li 完成了巨大的工作，将现在熟悉的 UI 带到了 Git 世界。TortoiseGit 启动得非常快，因为大部分 UI 都可以从 TortoiseSVN（以及其他工具，如 TortoiseMerge）获得，而且我在这个界面上做了很多工作。一般来说，如果你熟悉 TortoiseSVN，它可以让你很快上手 Git。开发人员煞费苦心地使用来自 TortoiseSVN 世界的术语并将它们映射到 git 命令。例如，revert确实在幕后执行git checkout <file>。

总的来说，以这种方式使用 Git 非常顺畅，我必须承认在使用 TortoiseGit 界面时学习了 Git：必须承认这是我学习的障碍。类似 TortoiseSVN 的日志查看器并不真正适用于分布式 vcs 工作流程（它工作得很好，你使用 Git 就像它是 SVN 一样），你只会在以后发现这一点，因为只有在有很多问题时才会出现问题，许多开发分支（gitk工具很多更好地处理此显示）。还有一个问题是，即使在使用 TortoiseGit 好几个月之后，我什至连最基本的 git 命令都不知道。TortoiseGit 并没有什么真正的问题，而且当它们确实出现错误时，它们会很快得到修复；主要问题似乎是 UI 中的设计问题（可能不止一个），由于开发历史较长，或者对 git 的惯用用法有更深入的了解，或者类似的事情，开发人员gitk和开发人员已经解决了这个问题。git gui

关于命令行使用：

真正应该感谢MSYS git 开发团队，他们甚至不厌其烦地完成他们所做的所有工作，如果没有他们的支持，mingw git 分支可能永远不会与主线合并。

我现在已经开始在Git Bash shell 中使用 msysgit 作为我几周以来唯一的 git 界面。我的印象是，虽然最初的学习似乎比较困难，但一旦获得了知识，其他一切都会变得容易。 在我看来， 这个参考是在命令行上学习 git 的真正更好的参考之一。

作为 Windows 上的 Git 用户，来自使用 TortoiseGit 接口到 git 的扩展体验，这是我工作流程的总结，它涵盖了 >95% 的所需内容（全部在 Git Bash 中，而不是Windows 命令外壳（命令））：

  • 检查修改

    状态

  • 切换分支

    git checkout some-feature-branch

  • 拿来

    获取

  • 显示日志（将进程与 shell&分离，以便 shell在允许更多命令之前gitk不会等待关闭）gitk

    吉特克&

  • 提交：要么

    • 简单提交：

      git commit -a -m "这是我的提交信息"

    • 复杂的多次连续提交：

      git gui

  • 推送到分支：master

    git push 起源大师

  • 合并（例如在 Fetch 之后）

    git合并原点/主

我还没有解决任何冲突，但到时候我会弄清楚的（欢迎评论:)。

编辑：对于解决冲突，kdiff3 是要走的路。设置很简单，从简单的差异到三路合并的一切都可以可靠而迅速地工作。

结论

  • Windows 上的 Git 功能齐全，可以像宣传的那样工作，并且不限于 Windows。

  • 性能一般都很好，但综合大怪可能会慢。

  • TortoiseGit 的界面很诱人，但最终并不令人满意：你应该尝试在命令行上学习 git。两者我都做过，而且这条路线效率更高。

于 2010-07-22T22:08:34.900 回答
9

  • 可疑的通配符支持：（文件
    有问题.gitignore）
    发送到底层操作系统特定的fnname()方法：见这个问题和那个（或那个）

  • git-svn 可能不是很快。
    资料来源：这个SO 答案。不过，它已经取得了一些不错的进展。

  • PATH需要进行调整以防止任何冲突
    Windows 和 bash 之间的某些命令是相同的。( find, cp, rm, ...)。
    看到这个答案。
    正如cjrh评论的那样，Git for Windows 默认情况下不会将其bin目录添加到PATH.

  • 可以进行一些 EOL 转换（Unix 与 Windows EOL）
    请参阅设置的权威性建议git autocrlf。
    来自 Git1.7.2的新的和改进的core.eol属性eol在msysgit中还没有。

于 2010-07-22T21:38:10.337 回答
3

（这可能更像是一个评论而不是一个答案，但我的代表还不在那里。）

我最近想知道同样的事情，我也无法挖掘太多。这是一个有趣的讨论（通过对 Git 的维基百科条目的引用发现）。

据我所知，主要问题是性能（特别是在 Cygwin 和/或大型存储库上）和文件系统问题（文件名不区分大小写，VFS 有限）。

纯粹主观/轶事：

我觉得 Git 在 Ubuntu 10.04 下本机运行比在同一台机器上 Win7 下的 Cygwin 上运行更愉快 - 以至于我几乎将所有自由 Web 开发工作都转移到 Ubuntu 上以利用它（除其他事项外）。我在工作时在我的 OSX 机器上学习了 Git，所以后来尝试在 Windows 上使用它几乎是痛苦的。msysgit 绝对是对 Cygwin 的改进，但它仍然受到 Windows 文件系统的限制。

编辑：显然，msysgit 阻塞了通过 UTF8 感知文件系统（如 Linux）输入 git 的文件名，这很糟糕。

我还偶然发现了GitSharp，这是一个 WIP 本机 Windows 实现（通过此博客评论发现）。

于 2010-07-22T22:04:09.110 回答