Visual Studio结合Team Foundation Server和Git进行代码管理

关于Visual Studio使用Git的文章不多，可能是用Visual Studio的大部分是.NET开发，用的是TFS和SVN这类集中式的管理居多吧。

笔者自己用Visual Studio里面的Git组件很多，但是里面的功能其实非常简陋，所以多半采用SourceTree进行管理。

SourceTree是Atlassian公司（JIRA和Confluence的公司）开发的免费的Git图形客户端，但同样需要git在本地安装，软件免费，但是需要注册Atlassian ID，注册的时候会需要输入Google验证码（大家都知道这是被墙的，注意翻墙）。

SourceTree Windows版本已经超过2.0.0，也支持Mac，遗憾的是不支持Linux，部分Java开发的朋友强烈呼吁Atlassian别歧视Linux……

Git具体的操作可以参见网上很多文章，在这不展开。本文使用码云作为Git服务端，创建项目过程在此略过，跟GitLab差不多的。

创建的项目是一个空的C#项目，第一步当然是要：

1. 克隆代码：

跟使用TFS和SVN一样的，Git每个Repository相当于不同的项目，每个项目建议放在一个新的目录下。

Clone到本地后，Visual Studio里面打开，会找到这个本地的Repository。但是这个管理器实在太弱了，而且缺少一个很重要的功能，所以笔者也不会使用它做关键操作。

2. 尝试修改一部分内容，看看Git和SVN的区别。

Git首先要暂存文件，在SourceTree里面很好操作，在Repository的第一个标签页里面暂存你需要提交的文件即可。黄色的是更改状态的，紫色问号是未知的文件，提交之后会变成红色的“R”或者保持黄色，或者绿色的加号意味着新增到Git。

某些文件是本机的，例如Visual Studio生成的隐藏文件，我们不应该提交到Git里面。而使用VS的Git插件是没有（或者我操作不成功）把文件加入Git忽略列表的这个关键功能，所以笔者用SourceTree：

对于部分文件，选择忽略精确的文件名即可：

可以看到暂存过的.getignore文件又被修改了，然后我们又暂存它。忽略列表是建议提交到Git里面的，方便团队成员本机的VS生成的这些忽略文件都不要提交上去污染代码：

3.推送到Git

一般SVN都是直接Commit就可以了，但是Git里面的Commit其实是提交到本机。由于Git是分布式的设计，所以本机也可以认为是一个Repository节点。而服务端是可以多个节点的，这些节点跟本机之间应该是同步的关系，而同步的关系是要求本机对于变更使用Push的方式推送到其他服务端节点的。

所以对于本机已经暂存了的文件，在Commit的时候可能要做多一个动作：推送更改到服务器以便其他小组成员可以获取，那么在点击提交的时候勾上左下角的立刻推送变更选项即可，这个选项推送到的是当前代码分支。

4. 丢弃不需要的修改（Undo）

在SVN等版本管理工具里面很重要的一个功能是未提交的功能放弃自己当前的修改，在Git里面通过对未暂存的文件“丢弃”：

5. 暂存修改文件推送到Origin

在当前本地分支右键，选择推送到origin而不是其他的推送选项，可以选择推送的具体分支名称。为什么需要选择呢？因为直接推送到master从开发规范性来说是不正常的。

通常master对应的是发布代码，就是已经上了生产线的代码才用master分支。那我们需要创建一个分支如何创建？笔者的习惯是推送到另一个分支。

6. 推送到dev而不是master

上面的菜单打开之后，我们手工把master改为dev分支。dev分支是开发主干分支，可以理解为svn常用的trunk。上传master分支只是初始化用，是时候推送到dev了：

点击推送后，origin多了dev分支，但是本地的分支还没有：

7. check out dev分支

再次推送到origin

8.推送到dev自己的分支

现在已经有相当于trunk的dev分支了，其实已经可以进行使用SVN的集中式开发了。但是我们用Git就应该使用Git的某些优秀特性。

Git的优秀特性在于每个人都有独立的工作分支，可以把自己分支中觉得成熟的代码提交到服务端，服务端与本机自己的分支的关联是很弱的。

基于这个特性，笔者的开发规范是在dev里面通过dev_前缀建立每个开发人员自己的dev分支：

推送之后，有了另一个dev分支在本地和origin

9. 从dev里面拉取最新的内容到自己的分支

建立了自己的分支，这样才可以进行真正的自己的开发，但是需要从其他成员的成熟代码里面获取代码，则需要把dev拉取到当前分支：

选择远端分支为dev：

本地分支合并之后多了一个版本，因为远端的版本是领先于自己的版本的。只需要在没问题的时候也推送到origin即可。

因为Git是多个中心的分布式架构，那么第一个服务端节点就叫做origin，这也就是我们上面屡次出现origin的原因，我们可以简单地理解成服务端中心节点（其实Git是去中心的）。

10. 停止跟踪Visual Studio自己生成的packages

通过码云（或者其他Git服务商提供的）C#模板创建的Git Repository不是完全够用的，有一些Git模板还没去掉的本机的东西，其中最占用Git空间和速度的，我认为是Visual Studio（Nuget）对每个解决方案项目生成的packages。下面的图演示如何忽略这文件夹（其实读者看上面去掉部分文件的操作已经可以猜到）：

11.在Git控制台里面合并到dev

不建议直接提交代码到dev，正如不建议直接提交代码到master一样，建议每个成员都发起Pull Request（也叫做Merge Request）进行合并：

选择源分支是自己的分支，目标分支选择dev：

本来Git设立的思想是必须审查代码和测试的，但是这里因为自己开发，就不勾选相关的选项，直接创建了。

确定没有问题就需要合并修改：

然后可以看到SourceTree里面有不同的分支操作，而不是直接在dev分支里面操作的，这样才能体现Git的分支与SVN不一样：

 

12. 对发布的版本打标签

在每次进行发布的时候，为了方便回溯，都建议对代码打tag，我们根据tag进行checkout和恢复：

笔者的开发规范是标签分为dev_、test_、stg_、release_开头，代表开发、测试、准现网、release（发布），后面跟版本号、日期（准确到分钟）进行标记：

记得打上推送标签的勾，不然这也是提交到本地的操作而已。

13. 对于打错了的标签，是可以删除标签的

删除标签也最好勾上移除所有远程标签，这样是为了让大家（团队其他成员）觉得操作有效，毕竟大家都是习惯集中式管理过来的嘛。