700字范文 > 在Visual Studio中使用Git [关闭]

在Visual Studio中使用Git [关闭]

时间：2023-02-23 15:26:30

作为一个长期的Visual SourceSafe用户（和仇恨）我正在讨论与同事转换到SVN ; 他建议改用Git 。显然，它可以在没有中央服务器的情况下用作点对点（我们是一个3开发团队）。

我无法找到任何关于将Git与Visual Studio集成的工具，但这样的事情是否存在？

在Visual Studio中使用Git有哪些技术可用？在开始之前，我需要了解它们之间的区别？

#1楼

微软有一个适用于Git的Visual Studio工具。它只支持Visual Studio （更新2）。

#2楼

微软最近宣布了Git for Visual studio （更新2）。我还没有玩过它，但这个视频看起来很有希望。

这是一个关于如何使用Visual Studio 中的Git的快速教程。

#3楼

截至-02-11， Visual Studio 的Microsoft Git插件也应该与Express版本一起使用。

#4楼

Visual Studio 本身支持Git。

见官方公告。

#5楼

目前在Visual Studio（和12）中有2个Git源代码控制选项：

Git源代码控制提供商 Microsoft Git Provider

我已经尝试了两个，并且发现第一个更成熟，并且具有更多功能。例如，它可以很好地兼顾togise git和git扩展，甚至可以暴露它们的功能。

注意：无论使用哪种扩展名，请确保从Tools -> Options -> Source control -> Plugin Selection启用它，以使其正常工作。

#6楼

Microsoft在Visual Studio中完成的Git支持对于基本工作（提交/获取/合并和推送）来说已经足够了。我的建议只是为了避免......

我非常喜欢GitExtensions （或者比例较低的SourceTree ）。因为看到DAG对我来说非常重要，要了解Git的工作原理。而且您更了解项目的其他贡献者所做的事情！

在Visual Studio中，您无法快速查看文件或提交之间的差异，也不能（添加到索引）并仅提交部分修改。浏览你的历史也不好......所有这些都以痛苦的经历告终！

而且，例如，GitExtensions捆绑了有趣的插件：后台提取，GitFlow，......现在，持续集成！

对于Visual Studio 的用户，如果您安装GitHub扩展，Git正在形成。但外部工具仍然更好;-)

#7楼

最新版本的Git Extensions现在支持Visual Studio （以及Visual Studio 和Visual Studio ）。

我发现使用Visual Studio 相当容易，并且Visual Studio 中的界面似乎相同。

#8楼

Git Source Control Provider是一个新的插件，它将Git与Visual Studio集成在一起。

#9楼

我使用Git和Visual Studio将Protocol Buffers的端口转换为C＃。我不使用GUI - 我只是保持命令行打开以及Visual Studio。

在大多数情况下它很好 - 唯一的问题是当你想重命名文件。 Git和Visual Studio都宁愿他们重命名它。我认为在Visual Studio中重命名它是可行的方法 - 只需要小心你之后在Git方面所做的事情。虽然这在过去有点痛苦，但我听说它实际上应该在Git方面非常无缝，因为它可以注意到内容将大致相同。（通常不完全相同 - 当你重命名类时，你倾向于重命名文件，IME。）

但基本上 - 是的，它运作正常。我是一个Git新手，但我可以把它做到我需要做的一切。确保你有bin和obj以及* .user的git ignore文件。

#10楼

1月，微软宣布他们正在为所有ALM产品添加完整的Git支持。他们发布了一个 Visual Studio 插件，增加了Git源代码控制集成。

或者，有一个名为Git Extensions的项目，包括Visual Studio ,,和的加载项，以及Windows Explorer集成。它经常更新并在几个项目中使用它，我发现它非常有用。

另一个选择是Git Source Control Provider 。

#11楼

我发现，与整个树一样工作的Git比IDE集成比基于文件的源控制工具或遵循checkout-edit-commit模式更少受益。当然有些情况下单击按钮进行历史检查可能会很好，但我不会错过这一点。

真正的必须做的是让你的.gitignore文件充满不应该在共享存储库中的东西。我的一般包含（以及其他内容）以下内容：

*.vcproj.*.user*.ncb*.aps*.suo

但这很大程度上是C ++的偏见，几乎没有使用任何类向导样式功能。

我的使用模式类似于以下内容。

Visual Studio中的代码，代码和代码。

快乐时（明智的中间点提交代码，切换到Git，阶段更改和审查差异。如果有什么显然错误切换回Visual Studio并修复，否则提交。

任何合并，分支，rebase或其他花哨的SCM东西在命令提示符下都很容易在Git中完成。 Visual Studio通常对在其下发生变化的事情感到相当满意，尽管如果您已经显着更改了项目文件，它有时可能需要重新加载一些项目。

我发现Git的用处超过了没有完全IDE集成的任何轻微不便，但它在某种程度上是一个品味问题。

#12楼

我在工作中看到了这一点（包括Subversion和Git）。 Visual Studio实际上有一个源代码控制集成API，允许您将第三方源代码控制解决方案集成到Visual Studio中。然而，由于几个原因，大多数人都不打扰它。

首先，API几乎假设您正在使用锁定结帐工作流程。其中有很多钩子要么实现起来要么昂贵，要么在你使用更现代的编辑 - 合并工作流程时没有任何意义。

第二个（相关的）是当你使用Subversion和Git都鼓励的编辑 - 合并工作流时，你并不需要Visual Studio集成。 SourceSafe与Visual Studio集成的主要杀手点是，您（和编辑）可以一目了然地告诉您拥有哪些文件，在编辑之前必须先检出哪些文件，哪些文件即使您想要也无法检出。然后它可以帮助您在编辑文件时执行您需要执行的任何修订控制伏都教。这些甚至都不是典型Git工作流程的一部分。

当您使用Git（或典型的SVN）时，您的修订控制交互都发生在开发会话之前或之后（一旦您完成所有工作和测试）。那时使用不同的工具真的不是太痛苦。你不是经常来回切换。