用GitBlit 和 VS GitSourceControlProvider 搭建基于 Http(s) 的 Git 工作平台
用GitBlit 和 VS GitSourceControlProvider 搭建基于 Http(s) 的 Git 工作平台
用GitBlit 和 VS GitSourceControlProvider 搭建基于 Http(s) 的 Git 工作平台
说明：
该方案可用于搭建基于Http(s)的git服务器，且客户端与visual studio集成，是一套很实用的企业内部git部署架构。
试过好几套window平台下的git方案，这套方案是最简单的，安全权限上也很容易控制。希望对大家有用~
架构：
服务器端：msysgit+gitblit
客户端：msysgit+tortoiseGit+ visual studio git source control provider
特点：
服务器端和客户端用https进行通讯（不用SSH，简单）
服务器端有网站支持，可进行用户权限控制，跟踪、统计，很直观
服务器端可派发证书给用户，用户安装证书后才可以访问服务器端GIT资源，安全
服务器端
1.安装msysgit
Msysgit是windows版本的git环境
下载地址：http://code.google.com/p/msysgit/
安装：
（1） 为了避免路径问题，安装目录最好没有空格和中文（如c:\git\） 。
（2）其它的一路默认下去即可
最好设置下系统路径:
path C:\ Git\bin;C:\Git\libexec\git-core;%PATH%
2.安装GitBlit
2.1简介
Gitblit是用java写的git服务端网站（类似github），以http/https方式提供git服务，可进行用户权限控制，跟踪、统计，直观、简单、强大、易用。
官方网站：http://gitblit.com/
下载完毕后解压到一个目录 （如d:\gitblit\ ）
2.2提供http服务
（1）先确保安装了java sdk
（2）运行gitblit.cmd即可，即可创建git网站.
（3）如果端口冲突跑不起来，打开data\gitblit.properties文件修改下端口参数，如：
server.httpPort = 8080 # http服务端口
server.httpBindInterface = localhost # http 绑定的地址（域名或ip）
首次登录， 管理员账户密码均为admin，请改掉！
进入后可设置代码库（respository），用户（user），团队（team）
默认的git仓库都建在data/git/ 文件夹内
更详细的操作可查看docs/文件夹内的文档
（5）可用git 命令进行操作，如：
Git clone http://admin@localhost:8080/git/test.git
2.3提供https服务
Gitblit可提供https服务，可在公网上提供安全访问渠道，可有效的鉴权、防窃听和防篡改。详细步骤可参照 http://gitblit.com/setup.html 。以下为简要说明：
（1）修改/data/gitblit.properties文件，如Server.httpPort = 0 # 设置为0的话会关闭http服务
Server.httpsPort = 8443 # 设置https服务端口
Server.httpsBindInterface = xxx.com # https 服务绑定的主机地址（域名或IP）
Server.certificateAlias = xxx.com # https ca证书绑定的主机地址（域名或IP）
Server.requireClientCertificates = true # 客户端要访问必须强制使用https协议
（2）创建https ssl证书
运行authority.cmd，进入Gitblit certificates authority 授权设置窗口：
录入CA证书基本信息
点击 按钮，弹出CA证书基本信息的录入窗口（该窗口在首次运行的时候也会弹出，填写一次就可以了）
Site name里面写该主机的ip地址或域名
创建主机CA证书（用于声明该主机的身份）
点击 按钮，弹出创建主机CA证书的窗口，录入保存。
创建用户个人证书（用于声明该用户的身份）
选中某个用户，点击右侧的new certificate按钮
查看证书
这两步操作完成后，可在/data/ certs/目录下看到生成的证书
可直接将里面的zip压缩包发给团队成员安装。
（3）用电子邮件将证书发送给团队成员（可选步骤）设置邮件服务器信息:
若有需要，可修改邮件模版文件
在之前的CA证书窗口中选择用户，点击 按钮将证书包发邮件给用户
（4）重新启动 gitblit.cmd客户端安装压缩包内的.p12证书 后，即可以https方式（ie或chrome）访问网站： https://www.xxx.com:8443/
更详尽的客户端使用说明请参考后继章节。
客户端
1.安装msysgit
Msysgit是windows版本的git环境
下载地址： http://code.google.com/p/msysgit/
安装注意：
（1） 为了避免路径问题，安装目录最好没有空格和中文 （如c:\git\）。
（2）可不用集成资源管理器菜单，因为后面的tortoisegit还会集成。
（3）其它的一路默认下去即可
最好设置下系统路径:
path C:\ Git\bin;C:\Git\libexec\git-core;%PATH%
2.安装HTTPS SSL客户端证书
2.1 查看管理员发给你的证书包
里面有若干的证书文件（ 假设用户名为cjh，且保存在d:\gitclient\_keys\ssl\cjh\目录下 ）：
Cjh.p12 包含了私钥和公钥和CA证书（供浏览器用）
Cjh.pem 包含了私钥和公钥和CA证书（供git客户端用）
--------------------------------------------------------------------------------------
Cjh.cer 私钥
Ca.cer 服务器端公钥证书
Readme.txt 安装指导
2.2 安装.p12证书
该.p12证书是供浏览器用的。双击安装.p12文件，一路默认，会提示你输入保护密码（问管理员）。安装完毕后可用IE和chrome访问服务端网站，firefox的p12安装请看安装指导。结束后可在internet选型->内容->证书内找到两个证书：
(1)受信任的根证书颁发机构： git.xxx.com的CA证书，用于标志该网站的身份
(2)个人证书：客户端用该证书连接git.xxx.com的https服务。
安装p12证书后，即可访问GIT服务器端网站，如 https://git.xxx.com:8443/
2.3 配置pem证书
该证书是git客户端用的。
openssl rsa -in "d:\gitclient\_keys\ssl\cjh\cjh.pem" -out "d:\gitclient\_keys\ssl\cjh\cjh.key"
git config --global http.sslcert "d:\gitclient\_keys\ssl\cjh\cjh.pem"
git config --global http.sslkey "d:\gitclient\_keys\ssl\cjh\cjh.key"
git config --global http.sslVerify false
git config --global --list
设置.pem证书成功后就可以用git访问服务器https git服务了
3.安装tortoiseGit
http://code.google.com/p/tortoisegit/wiki/Download
一路默认过去即可。安装成功后，资源管理器右键菜单将集成TortoiseGit。
4.安装VisualStudio GIT插件
工具->扩展管理器->搜索并安装git source control provider,重新启动visual studio
工具->选项->源代码管理(source control): 选择git source control provider
设置git source control provider中的tortosegit路径C:\Program Files\TortoiseGit\bin\TortoiseGitProc.exe
5.GIT基本操作
5.1 clone仓库
在d:\gitclient\目录内空白处，右键菜单->Git Clone，从服务器端将库克隆下来，地址
https://admin@git.xxx.com:8443/git/test.git
也可以直接打命令行：
git clone https://admin@git.xxx.com:8443/git/test.git d:\gitclient\test
Cloning into 'test'...
remote: Counting objects: 11, done
remote: Finding sources: 100% (11/11)
remote: Getting sizes: 100% (7/7)
remote: Total 11 (delta 0), reused 11 (delta 0)
Unpacking objects: 100% (11/11), done.
5.2 Commit（到本地库）
在visualstudio中用右键菜单进行commit操作（若未安装tortoisegit，可直接用git bash命令行工具）
Commit时必须写点东西；commit结束后可以push到服务器端。
注：commit全选文件的技巧：用shift键全选，再点击checkbox。
5.3 Push（到服务器库）
转载请注明出处： http://surfsky.cnblogs.com
分类: 杂项
标签: Git gitblit tortoiseGit msysgit gitSourceControl
你所需要知道的一些git 的使用命令：Git的缺点 2013-03-18 13:14 by Terry_龙, 781 阅读, 0 评论, 收藏 , 编辑
=== SHA1 的弱点 ===
随着时间的推移，密码学家发现越来越多的SHA1的弱点。已经发现对对资源雄厚的组织
哈希冲撞是可能的。在几年内，或许甚至一个一般的PC也将有足够计算能力悄悄摧毁一
个Git仓库。
希望在进一步研究摧毁SHA1之前，Git能迁移到一个更好的哈希算法。
=== 微软 Windows ===
Git在微软Windows上可能有些繁琐：
- http://cygwin.com/[Cygwin] ，, 一个Windows下的类Linux的环境，包含一个 http://cygwin.com/packages/git/[ 一个Git在Windows下的移植].
- http://code.google.com/p/msysgit/[基于MSys的Git] 是另一个，要求最小运行时支持，不过一些命令不能马上工作。
=== 不相关的文件 ===
如果你的项目非常大，包含很多不相关的文件，而且正在不断改变，Git可能比其他系统
更不管用，因为独立的文件是不被跟踪的。Git跟踪整个项目的变更，这通常才是有益的。
一个方案是将你的项目拆成小块，每个都由相关文件组成。如果你仍然希望在同一个资
源库里保存所有内容的话，可以使用 *git submodule* 。
=== 谁在编辑什么？ ===
一些版本控制系统在编辑前强迫你显示地用某个方法标记一个文件。尽管这种要求很烦
人，尤其是需要和中心服务器通讯时，不过它还是有以下两个好处的：
1. 比较速度快，因为只有被标记的文件需要检查。
2. 可以知道谁在这个文件上工作，通过查询在中心服务器谁把这个文件标记为编辑状
态。
使用适当的脚本，你也可以使Git达到同样的效果。这要求程序员协同工作，当他编辑一
个文件的时候还要运行特定的脚本。
=== 文件历史 ===
因为Git记录的是项目范围的变更，重造单一文件的变更历史比其他跟踪单一文件的版本
控制系统要稍微麻烦些。
好在麻烦还不大，也是值得的，因为Git其他的操作难以置信地高效。例如，`git
checkout`比`cp -a`都快，而且项目范围的delta压缩也比基于文件的delta集合的做法
好多了。
=== 初始克隆 ===
The initial cost is worth paying in the long run, as most future operations will then be fast and offline. However, in some situations, it may be preferable to create a shallow clone with the `--depth` option. This is much faster, but the resulting clone has reduced functionality.
当一个项目历史很长后，与在其他版本系统里的检出代码相比，创建一个克隆的开销会
大的多。
长远来看，开始付出的代价还是值得付出的，因为大多将来的操作将由此变得很快，并
可以离线完成。然而，在一些情况下，使用`--depth`创建一个浅克隆比较划算些。这种
克隆初始化的更快，但得到克隆的功能有所削减。
=== 不稳定的项目 ===
变更的大小决定写入的速度快慢是Git的设计。一般人做了小的改动就会提交新版本。这
里一行臭虫修改，那里一个新功能，修改掉的注释等等。但如果你的文件在相邻版本之
间存在极大的差异，那每次提交时，你的历史记录会以整个项目的大小增长。
任何版本控制系统对此都束手无策，但标准的Git用户将遭受更多，因为一般来说，历史
记录也会被克隆。
应该检查一下变更巨大的原因。或许文件格式需要改变一下。小修改应该仅仅导致几个
文件的细小改动。
或许，数据库或备份/打包方案才是正选，而不是版本控制系统。例如，版本控制就不适
宜用来管理网络摄像头周期性拍下的照片。
如果这些文件实在需要不断更改，他们实在需要版本控制，一个可能的办法是以中心的
方式使用Git。可以创建浅克隆，这样检出的较少，也没有项目的历史记录。当然，很多
Git工具就不能用了，并且修复必须以补丁的形式提交。这也许还不错，因为似乎没人需
要大幅度变化的不稳定文件历史。
另一个例子是基于固件的项目，使用巨大的二进制文件形式。用户对固件文件的变化历
史没有兴趣，更新的压缩比很低，因此固件修订将使仓库无谓的变大。
这种情况，源码应该保存在一个Git仓库里，二进制文件应该单独保存。为了简化问题，
应该发布一个脚本，使用Git克隆源码，对固件只做同步或Git浅克隆。
=== 全局计数器 ===
一些中心版本控制系统维护一个正整数，当一个新提交被接受的时候这个整数就增长。Git则是通过哈希值来记录所有变更，这在大多数情况下都工作的不错。
但一些人喜欢使用整数的方法。幸运的是，很容易就可以写个脚本，这样每次更新，中心Git仓库就增大这个整数，或使用tag的方式，把最新提交的哈希值与这个整数关联起来。
每个克隆都可以维护这么个计数器，但这或许没什么用，因为只有中心仓库以及它的计数器对每个人才有意义。
=== 空子目录 ===
空子目录不可加入管理。可以通过创建一个空文件以绕过这个问题。
Git的当前实现，而不是它的设计，是造成这个缺陷的原因。如果运气好，一旦Git得到
更多关注，更多用户要求这个功能，这个功能就会被实现。
=== 初始提交 ===
传统的计算机系统从0计数，而不是1。不幸的是，关于提交，Git并不遵从这一约定。很
多命令在初始提交之前都不友好。另外，一些极少数的情况必须作特别地处理。例如重
订一个使用不同初始提交的分支。
Git将从定义零提交中受益：一旦一个仓库被创建起来，HEAD将被设为包含20个零字节
的字符串。这个特别的提交代表一棵空的树，没有父节点，早于所有Git仓库。
然后运行git log，比如，通知用户至今还没有提交过变更，而不是报告致命错误并退出。
这与其他工具类似。
每个初始提交都隐式地成为这个零提交的后代。
不幸的是还有更糟糕的情况。如果把几个具有不同初始提交的分支合并到一起，之后的
重新修订不可避免的需要人员的介入。
=== 接口怪癖 ===
对提交A和提交B，表达式“A..B”和“A...B”的含义，取决于命令期望两个终点还是一
个范围。参见 *git help diff* 和 *git help rev-parse* 。
分类: git
标签: git , git 的缺点
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息查看更多关于用GitBlit 和 VS GitSourceControlProvider 搭建基于 Http(s的详细内容...