发帖 回复
返回列表
  • 12759阅读
  • 2回复

扇贝词典项目开源，GitHub使用基础命令解释 [复制链接]

 上一主题 下一主题
离线jeffreylee
论坛版主
 
只看楼主 倒序阅读 楼主  发表于: 2013-04-03
内容尚在不断更新中，来自我的一篇工作日志，随着对git以及github的不断熟悉，持续更新日志内容，点击进入

GitHub日常操作常用命令：
$ git clone git@github.com:vipjeffreylee/ShanbayDict.git
注释：把github服务器上面的开源项目扇贝词典代码仓库克隆到本地，git是分布式版本控制，现在本地跟github的数据完全一致扇贝词典项目现在我设置了三个分支，master、develop和gh-pages，master是主分支，稳定版本发布在这里，顾名思义，develop分支是生产分支，平时开发工作在这个开发分支。gh-pages分支存放了项目发布网站的网页代码，目前只有index.htm一个文件，存放了，项目的简单介绍和安装包下载地址。
$git checkout develop
切换工作目录到develop分支。



一、git命令行客户端的安装
ubuntu：sudo apt-get install git
windows：下载msysgit，http://msysgit.github.com/
二、配置链接环境
2.1 git全局环境，也就是代码所有者的名字和邮箱
$ git config --global user.name "Jeffrey Lee"
$ git config --global user.email jeffrey@example.com
2.2生成ssh链接github的密钥
$ ssh-keygen  -C  ' jeffrey@gmail.com'  -t  rsa
根据提示输入密钥管理密码，看清密钥存放位置，需要把公钥文本复制到github，别到时候找不到了
2.3拷贝公钥到github
找到id_rsa.pub，文件，用记事本打开，把内容复制，到github的网站->Account Setting->SSH KEYS->添加ADD SSH KEY
2.4测试链接
￥ssh -T git@github.com
看到如下信息返回，说明已经链接成功
Hi vipjeffreylee! You've successfully authenticated,
2.5创建本地仓库，pull远程gihub上的代码仓库到本地(用我的扇贝词典工程为例)
$ mkdir ShanbayDict
$ cd ShanbayDict/
$ git init
$ git remote add origin git@github.com:vipjeffreylee/ShanbayDict.git
$git pull
远程代码拉到本地仓库了,看清楚了，是拉倒本地仓库 ，你现在查看ShanbayDict目录下，没发现有文件
$git checkout master
现在好了，文件出来了，这就是仓库跟工作目录的区别，也是分布式版本控制git的特点，本地也是完整的仓库，在隐藏目录.git里面，内容完全等同于远程gihub仓库的内容，工作目录需要checkout，工作目录里面不像svn，在每个目录下都要建立.svn文件，污染工作目录内容




-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
关于tag：
tag是对一次commit提交的别名，用来标识关键版本，方便对指定版本的回滚和下载，tag命令只是在本地仓库打标签，git push命令不会把tag上传到github，只有通过显式命令才能分享标签到远端仓库。
1.push单个tag，命令格式为：git push origin [tagname]例如：git push origin v1.0 #将本地v1.0的tag推送到远端服务器
2.push所有tag，命令格式为：git push [origin] --tags例如：git push --tags或git push origin --tags
更加详细的tag解释：


同大多数 VCS 一样，Git 也可以对某一时间点上的版本打上标签。人们在发布某个软件版本（比如 v1.0 等等）的时候，经常这么做。本节我们一起来学习如何列出所有可用的标签，如何新建标签，以及各种不同类型标签之间的差别。
列显已有的标签，列出现有标签的命令非常简单，直接运行 git tag 即可：
$ git tag
v0.1
v1.3
显示的标签按字母顺序排列，所以标签的先后并不表示重要程度的轻重。我们可以用特定的搜索模式列出符合条件的标签。在 Git 自身项目仓库中，有着超过 240 个标签，如果你只对 1.4.2 系列的版本感兴趣，可以运行下面的命令：
$ git tag -l 'v1.4.2.*'
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4
新建标签
Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签，以便保留相关信息；当然，如果只是临时性加注标签，或者不需要旁注额外信息，用轻量级标签也没问题。
含附注的标签
创建一个含附注类型的标签非常简单，用 -a （译注：取 annotated 的首字母）指定标签名字即可：
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v0.1
v1.3
v1.4
而 -m 选项则指定了对应的标签说明，Git 会将此说明一同保存在标签对象中。如果在此选项后没有给出具体的说明内容，Git 会启动文本编辑软件供你输入。可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。
$ git show v1.4
tag v1.4
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sun Feb 8 19:02:46 2009 -0800


    Merge branch 'experiment'
我们可以看到在提交对象信息上面，列出了此标签的提交者和提交时间，以及相应的标签说明。
签署标签
如果你有自己的私钥，还可以用 GPG 来签署标签，只需要把之前的 -a 改为 -s （译注： 取 Signed 的首字母）即可：
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gee-mail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
现在再运行 git show 会看到对应的 GPG 签名也附在其内：
$ git show v1.5
tag v1.5
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 15:22:20 2009 -0800
my signed 1.5 tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN
Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/
=WryJ
-----END PGP SIGNATURE-----
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sun Feb 8 19:02:46 2009 -0800
    Merge branch 'experiment'
稍后我们再学习如何验证已经签署的标签。
轻量级标签：轻量级标签实际上就是一个保存着对应提交对象的校验和信息的文件。要创建这样的标签，一个 -a，-s 或 -m 选项都不用，直接给出标签名字即可：
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
现在运行 git show 查看此标签信息，就只有相应的提交对象摘要：
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Sun Feb 8 19:02:46 2009 -0800
    Merge branch 'experiment'
验证标签：可以使用 git tag -v [tag-name] （译注：取 verify 的首字母）的方式验证已经签署的标签。此命令会调用 GPG 来验证签名，所以你需要有签署者的公钥，存放在 keyring 中，才能验证：
$ git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
type commit
tag v1.4.2.1
tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700
GIT 1.4.2.1
Minor fixes since 1.4.2, including git-mv and git-http with alternates.
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Good signature from "Junio C Hamano <junkio@cox.net>"
gpg:                 aka "[jpeg image of size 1513]"
Primary key fingerprint: 3565 2A26 2040 E066 C9A7  4A7D C0C6 D9A4 F311 9B9A
若是没有签署者的公钥，会报告类似下面这样的错误：
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.4.2.1'
后期加注标签：
你甚至可以在后期对早先的某次提交加注标签。比如在下面展示的提交历史中：
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
我们忘了在提交 “updated rakefile” 后为此项目打上版本号 v1.2，没关系，现在也能做。只要在打标签的时候跟上对应提交对象的校验和（或前几位字符）即可：
$ git tag -a v1.2 9fceb02
可以看到我们已经补上了标签：
$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5
$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date:   Sun Apr 27 20:43:35 2008 -0700
    updated rakefile...
分享标签
默认情况下，git push 并不会把标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。其命令格式如同推送分支，运行 git push origin [tagname] 即可：
$ git push origin v1.5
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag]         v1.5 -> v1.5
如果要一次推送所有（本地新增的）标签上去，可以使用 --tags 选项：
$ git push origin --tags
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag]         v0.1 -> v0.1
* [new tag]         v1.2 -> v1.2
* [new tag]         v1.4 -> v1.4
* [new tag]         v1.4-lw -> v1.4-lw
* [new tag]         v1.5 -> v1.5
现在，其他人克隆共享仓库或拉取数据同步后，也会看到这些标签




关于.gitignore,忽略某些文件的版本管理


.gitignore文件可以定义要忽略的文件。详细规则见http://www.kernel.org/pub/software/scm/git/docs/gitignore.html
过滤文件夹: /build/
过滤某种类型的文件:  *.user
过滤某个文件: /Build/Products/test.app
!开头表示不过滤： !*.c , !/dir/subdir/
支持通配符： *.[oa] 过滤repo中所有以.o或者.a为扩展名的文件
有三种方法应用过滤：
对该项目所有参与者过滤:
将 .gitignore 文件放在工作目录的根目录，编辑.gitignore完成后提交
git add .gitignore
仅对自己仓库过滤:
添加/编辑你工作目录的$GIT_DIR/info/exclude,例如你的working copy目录是
~/src/project1 , 则路径为
~/src/project1/.git/info/exclude
系统全局过滤
创建一个ignore文件，名字随意起，比如我的放在 ~/.gitglobalignore ，然后配置git：
$ core.excludesfile = ~/.gitglobalignore
.gitignore文件示例:
.DS_Store
### build directory
iMochaApp/build/
iMochaSDK/build/
### Testing projects directory
/Testing/
关于git config push.default matching
这是新版git比较智能的地方，让你定义push的缺省操作
git config push.default current
current意思是每次push仅仅push当前的分支，如果设置为matching的话，会push所有的有改动的branch。我认为还是current比较好，我的行为我做主，不需要那么多自动动作。
关于汉字乱码：
从帖子 http://topic.csdn.net/u/20110106/20/f11ef8dd-44ec-478e-b78a-73240bcdde43.html
处摘抄提炼而来
原理：强制log统一使用utf-8编码。
1.在 etc/gitconfig 中添加：
[python] view plaincopy
[gui]  
    encoding = utf-8  
[i18n]  
    commitencoding = utf-8  
    logoutputencoding = gbk  
说明：
1) gui.encoding = utf-8 解决在 $ git gui 和 gitk 里中文乱码。
2) i18n.commitencoding = utf-8 设置 commit log 提交时使用 utf-8 编码，可避免服务器上乱码，同时与Unix上的提交保持一致！
3) i18n.logoutputencoding = gbk 使得在 $ git log 时将 utf-8 编码转换成 gbk 编码，解决 MSYS Bash 中 $ git log 乱码。
2.使得 $ git log 可以正常显示中文（配合i18n.logoutputencoding = gbk)，在 etc/profile 中添加：
[c-sharp] view plaincopy
export LESSCHARSET=utf-8  
网上流传的方法都没有使用logoutputencoding = gbk选项。
而我认为这才是最终解决中文commit log乱码的根本方案。
MsysGit的中文乱码，有两方面的原因：
1. MSYS Bash不支持utf-8编码的中文显示，而且没有自动将utf-8编码转换成gbk编码的选项。
2. Git GUI无法自动检测当前文件编码，导致只能由用户指定：encoding = utf-8 ，弊端是非utf-8编码的文本将显示乱码。
也鉴于这个原因，如果是开发跨平台项目，建议统一使用UTF-8编码，以尽可能的解决中文乱码问题。
另外关于这个问题：请教如何在 MSYS 的 Bash 中将所有输出自动从 UTF-8 转换到GBK么？
这个我不知能否做到，但是可以让bash正确显示UTF-8字符。因为msys的bash和windows的cmd相关的，也是内含了windows的代码页。他默认的代码页是GBK的。
在bash里输入
[c-sharp] view plaincopy
c:/windows/system32/chcp.com 65001    
然后按Alt-space，选择属性，在字体栏里选择字体为非点阵字体（在我这里为Consolas和Lucida Console字体），然后在bash里输入utf-8输出的命令，你会发现就不会乱码了。缺点是gbk输出的就会乱码。
更多资讯，请关注我的微博
回复
举报
分享到 淘江湖 新浪 QQ微博 QQ空间 开心 人人 豆瓣 网易微博 百度 鲜果 白社会 飞信
离线XChinux
总版主
只看该作者 1楼 发表于: 2013-04-03
比较详细，感兴趣的人员可以去参与这个的开发，上github.
二笔 openSUSE Vim N9 BB10 XChinux@163.com 网易博客 腾讯微博
承接C++/Qt、Qt UI界面、PHP及预算报销系统开发业务
回复
举报
离线hohos
禁止发言
只看该作者 2楼 发表于: 2013-04-27
支持支持

单单GIT命令的实际使用经验就很不错了
回复
举报
发帖 回复
返回列表
快速回复
限100 字节
 
上一个 下一个