Git服务整理总结王超群.docx
- 文档编号:30146402
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:25
- 大小:60.70KB
Git服务整理总结王超群.docx
《Git服务整理总结王超群.docx》由会员分享,可在线阅读,更多相关《Git服务整理总结王超群.docx(25页珍藏版)》请在冰豆网上搜索。
Git服务整理总结王超群
git阶段整理总结
内容:
git服务器阶段整理总结
日期:
20140623
作者:
王超群
备注:
内容来源pro_git_中文版本.pdf
git管理下文件的三种状态
接下来要讲的概念非常重要。
对于任何一个文件,在Git内都只有三种状态:
已提交(committed),已修改(modified)和已暂存(staged)。
已提交表示该文件已经被安全地保存在本地数据库中了;
已修改表示修改了某个文件,但还没有提交保存;
已暂存表示把已修改的文件放在下次提交时要保存的清单中。
由此我们看到Git管理项目时,文件流转的三个工作区域:
Git的本地数据目录,工作目录以及暂存区域。
每个项目都有一个git目录,它是Git用来保存元数据和对象数据库的地方。
该目录非常重要,每次克隆镜像仓库的时候,实际拷贝的就是这个目录里面的数据。
从项目中取出某个版本的所有文件和目录,用以开始后续工作的叫做工作目录。
这些文件实际上都是从git目录中的压缩对象数据库中提取出来的,接下来就可以在工作目录中对这些文件进行编辑。
所谓的暂存区域只不过是个简单的文件,一般都放在git目录中。
有时候人们会把这个文件叫做索引文件,不过标准说法还是叫暂存区域。
基本的Git工作流程如下所示:
1.在工作目录中修改某些文件。
2.对这些修改了的文件作快照,并保存到暂存区域。
3.提交更新,将保存在暂存区域的文件快照转储到git目录中。
所以,我们可以从文件所处的位置来判断状态:
如果是git目录中保存着的特定版本文件,就属于已提交状态;如果作了修改并已放入暂存区域,就属于已暂存状态;如果自上次取出后,作了修改但还没有放到暂存区域,就是已修改状态。
我们会进一步了解个中细节,并学会如何善用这些状态,以及如何跳过暂存环节。
git中获取帮助
$githelp
$git
比如,要学习config命令可以怎么用,运行:
$githelpconfig
作者author和提交者committer的区别
Author是实际做出修改者
Committer是实际的提交者
首次运行git服务器的配置
在linux系统上
•/etc/gitconfig文件:
系统中对所有用户都普遍适用的配置。
若使用gitconfig时用--system选项,读写的就是这个文件。
•~/.gitconfig文件:
用户目录下的配置文件只适用于该用户。
若使用gitconfig时用--global选项,读写的就是这个文件。
•当前项目的git目录中的配置文件(也就是工作目录中的.git/config文件):
这里的配置仅仅针对当前项目有效。
每一个级别的配置都会覆盖上层的相同配置,所以.git/config里的配置会覆盖/etc/gitconfig中的同名变量。
在Windows系统上,Git会找寻用户主目录下的.gitconfig文件。
主目录即$HOME变量指定的目录,一般都是C:
\DocumentsandSettings\$USER。
此外,Git还会尝试找寻/etc/gitconfig文件,只不过看当初Git装在什么目录,就以此作为根目录来定位。
例如:
$gitconfig--globaluser.name"JohnDoe"
$gitconfig--globaluser.emailjohndoe@
$gitconfig--globalcore.editoremacs
$gitconfig--globalmerge.toolvimdiff
$gitconfig--list
$gitconfiguser.name
对已有的项目进行git管理
要对现有的某个项目开始用Git管理,只需到此项目所在的目录,执行:
$gitinit
初始化后,在当前目录下会出现一个名为.git的目录,所有Git需要的数据和资源都存放在这个目录中。
不过目前,仅仅是按照既有的结构框架初始化好了里边所有的文件和目录,但我们还没有开始跟踪管理项目中的任何一个文件。
如果当前目录下有几个文件想要纳入版本控制,需要先用gitadd命令告诉Git开始对这些文件进行跟踪,然后提交:
从已有的仓库clone一份镜像出来
$gitclonegit:
//mygrit
现在我们手上已经有了一个真实项目的Git仓库,并从这个仓库中取出了所有文件的工作拷贝。
接下来,对这些文件作些修改,在完成了一个阶段的目标之后,提交本次更新到仓库。
请记住,工作目录下面的所有文件都不外乎这两种状态:
已跟踪或未跟踪。
已跟踪的文件是指本来就被纳入版本控制管理的文件,在上次快照中有它们的记录,工作一段时间后,它们的状态可能是未更新,已修改或者已放入暂存区。
而所有其他文件都属于未跟踪文件。
它们既没有上次更新时的快照,也不在当前的暂存区域。
初次克隆某个仓库时,工作目录中的所有文件都属于已跟踪文件,且状态为未修改。
个人总结:
android系统中,第一次clone下来的数据中的文件是全部跟踪的,并且对于我们来说也必须是跟踪的,因为都是源代码,这个时候可以在管理目录下新建一个.gitignore文件,将编译产生的文件放进去,做好之后,当编译android后,执行gitstatus,只会显示之前你修改的文件,不会把编译产生的文件也显示出来
gitaddxx作用
gitadd后可以接要跟踪的文件或目录的路径。
如果是目录的话,就说明要递归跟踪所有该目录下的文件
假如编译文件A,B后,gitadd后,现在两个文件A,B都已暂存,下次提交时就会一并记录到仓库。
假设此时,你想要在文件A里再加条注释,重新编辑存盘后,准备好提交。
不过且慢,再运行gitstatus看看:
A文件出现了两次!
一次算未暂存,一次算已暂存,这怎么可能呢?
好吧,实际上Git只不过暂存了你运行gitadd命令时的版本,如果现在提交,那么提交的是gitadd过的版本,而非当前工作目录中的版本。
所以,运行了gitadd之后又作了修订的文件,需要重新运行gitadd把最新版本重新暂存起来
.gitignore文件作用
一般我们总会有些文件无需纳入Git的管理,也不希望它们总出现在未跟踪文件列表。
通常都是些自动生成的文件,像是日志或者编译过程中创建的等等。
我们可以创建一个名为.gitignore的文件,列出要忽略的文件模式,要养成一开始就设置好.gitignore文件的习惯,以免将来误提交这类无用的文件
.gitignore的格式规范如下:
•所有空行或者以注释符号#开头的行都会被Git忽略。
•可以使用标准的glob模式匹配。
•匹配模式最后跟反斜杠(/)说明要忽略的是目录。
•要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号(!
)取反。
所谓的glob模式是指shell所使用的简化了的正则表达式。
星号(*)匹配零个或多个任意字符;[abc]匹配任何一个列在方括号中的字符(这个例子要么匹配一个a,要么匹配一个b,要么匹配一个c);问号(?
)只匹配一个任意字符;如果在方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如[0-9]表示匹配所有0到9的数字)。
我们再看一个.gitignore文件的例子:
#此为注释–将被Git忽略
*.a#忽略所有.a结尾的文件
!
lib.a#但lib.a除外
/TODO#仅仅忽略项目根目录下的TODO文件,不包括subdir/TODO
build/#忽略build/目录下的所有文件
doc/*.txt#会忽略doc/notes.txt但不包括doc/server/arch.txt
gitdiff作用
要查看尚未暂存的文件更新了哪些部分,不加参数直接输入gitdiff
此命令比较的是工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后还没有暂存起来的变化内容
若要看已经暂存起来的文件和上次提交时的快照之间的差异,可以用gitdiff--cached命令。
(Git1.6.1及更高版本还允许使用gitdiff--staged,效果是相同的,但更好记些。
gitcommit作用
gitcommit提交之前请一定要确认还有什么修改过的或新建的文件还没有gitadd过,否则提交的时候不会记录这些还没暂存起来的变化。
所以,每次准备提交前,先用gitstatus看下,是不是都已暂存起来了,然后再运行提交命令gitcommit这种方式会启动文本编辑器以便输入本次提交的说明。
(默认会启用shell的环境变量$EDITOR所指定的软件,一般都是vim或emacs。
当然也可以按照第一章介绍的方式,使用gitconfig--globalcore.editor命令设定你喜欢的编辑软件。
)编辑器会显示一些文本信息,可以看到,默认的提交消息包含最后一次运行gitstatus的输出,放在注释行里,另外开头还有一空行,供你输入提交说明。
你完全可以去掉这些注释行,不过留着也没关系,多少能帮你回想起这次更新的内容有哪些。
(如果觉得这还不够,可以用-v选项将修改差异的每一行都包含到注释中来。
)退出编辑器时,Git会丢掉注释行,将说明内容和本次更新提交到仓库。
也可以使用-m参数后跟提交说明的方式,在一行命令中提交更新:
$gitcommit-m"Story182:
Fixbenchmarksforspeed"
记住,提交时记录的是放在暂存区域的快照,任何还未暂存的仍然保持已修改状态,可以在下次提交时纳入版本管理。
每一次运行提交操作,都是对你项目作一次快照,以后可以回到这个状态,或者进行比较。
跳过使用暂存区域
尽管使用暂存区域的方式可以精心准备要提交的细节,但有时候这么做略显繁琐。
Git提供了一个跳过使用暂存区域的方式,只要在提交的时候,给gitcommit加上-a选项,Git就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过gitadd步骤,gitcommit-a注意是将修改的文件暂存后一并调交,是会暂存它的
git中删除某些文件
要从Git中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。
可以用gitrm命令完成此项工作(注意,执行gitrm后,要gitcommit提交才会最终生效),并连带从工作目录中删除指定的文件,这样以后就不会出现在未跟踪文件清单中了。
如果只是简单地从工作目录中手工删除文件,运行gitstatus时就会在“Changedbutnotupdated”部分(也就是_未暂存_清单)
git取消跟踪但不删除文件
另外一种情况是,我们想把文件从Git仓库中删除(亦即从暂存区域移除),但仍然希望保留在当前工作目录中。
换句话说,仅是从跟踪清单中删除。
比如一些大型日志文件或者一堆.a编译文件,不小心纳入仓库后,要移除跟踪但不删除文件,以便稍后在.gitignore文件中补上,用--cached选项即可:
$gitrm--cachedreadme.txt//此命令会从将readme.txt从暂存区删除,然后刷新暂存区,提交生效
注意:
后面可以列出文件或者目录的名字,也可以使用glob模式。
比方说:
$gitrmlog/\*.log
注意到星号*之前的反斜杠\,因为Git有它自己的文件模式扩展匹配方式,所以我们不用shell来帮忙展开(译注:
实际上不加反斜杠也可以运行,只不过按照shell扩展的话,仅仅删除指定目录下的文件而不会递归匹配。
上面的例子本来就指定了目录,所以效果等同,但下面的例子就会用递归方式匹配,所以必须加反斜杠。
)。
此命令删除所有log/目录下扩展名为.log的文件。
类似的比如:
$gitrm\*~
会递归删除当前目录及其子目录中所有~结尾的文件。
git文件改名
不像其他的VCS系统,Git并不跟踪文件移动操作。
如果在Git中重命名了某个文件,仓库中存储的元数据并不会体现出这是一次改名操作。
不过Git非常聪明,它会推断出究竟发生了什么,至于具体是如何做到的,我们稍后再谈。
既然如此,当你看到Git的mv命令时一定会困惑不已。
要在Git中对文件改名,可以这么做:
$gitmvfile_fromfile_to
如此分开操作,Git也会意识到这是一次改名,所以不管何种方式都一样。
当然,直接用gitmv轻便得多,不过有时候用其他工具批处理改名的话,要记得在提交前删除老的文件名,再添加新的文件名。
gitlog妙用
默认不用任何参数的话,gitlog会按提交时间列出所有的更新,最近的更新排在最上面。
每次更新都有一个SHA-1校验和、作者的名字和电子邮件地址、提交时间,最后缩进一个段落显示提交说明.
gitlog有许多选项可以帮助你搜寻感兴趣的提交,接下来我们介绍些最常用的。
我们常用-p选项展开显示每次提交的内容差异,用-2则仅显示最近的两次更新还有个常用的--pretty选项,可以指定使用完全不同于默认格式的方式展示提交历史。
比如用oneline将每个提交放在一行显示,这在提交数很大时非常有用。
、
$gitlog--pretty=oneline
但最有意思的是format,可以定制要显示的记录格式,这样的输出便于后期编程提取析,像这样:
$gitlog--pretty=format:
"%h-%an,%ar:
%s"
用oneline或format时结合--graph选项,可以看到开头多出一些ASCII字符串表示的简单图形,形象地展示了每个提交所在的分支及其分化衍合情况
有时候图形化工具更容易展示历史提交的变化,随Git一同发布的gitk就是这样一种工具。
它是用Tcl/Tk写成的,基本上相当于gitlog命令的可视化版本,凡是gitlog可以用的选项也都能用在gitk上。
在项目工作目录中输入gitk命令后,就会启动图形界面,上半个窗口显示的是历次提交的分支祖先图谱,下半个窗口显示当前点选的提交对应的具体差异
修改最后一次提交
有时候我们提交完了才发现漏掉了几个文件没有加,或者提交信息写错了。
想要撤消刚才的提交操作,可以使用--amend选项重新提交:
$gitcommit--amend
此命令将使用当前的暂存区域快照提交。
如果刚才提交完没有作任何改动,直接运行此命令的话,相当于有机会重新编辑提交说明,而所提交的文件快照和之前的一样。
启动文本编辑器后,会看到上次提交时的说明,编辑它确认没问题后保存退出,就会使用新的提交说明覆盖刚才失误的提交。
如果刚才提交时忘了暂存某些修改,可以先补上暂存操作,然后再运行--amend提交
取消已经暂存的文件
可以使用gitresetHEAD
查看当前配置有哪些远程仓库
查看当前配置有哪些远程仓库,可以用gitremote命令,它会列出每个远程库的简短
名字。
在克隆完某个项目后,至少可以看到一个名为origin的远程库,Git默认使用这个名字来标识你所克隆的原始仓库也可以加上-v选项(译注:
此为—verbose的简写,取首字母),显示对应的克隆地址
添加远程仓库
要添加一个新的远程仓库,可以指定一个简单的名字,以便将来引用,运行gitremoteadd[shortname][url]
$gitremoteaddpbgit:
//
现在可以用字串pb指代对应的仓库地址了。
比如说,要抓取所有Paul有的,但本地仓库没有的信息,可以运行gitfetchpb现在,paul的主干分支(master)已经完全可以在本地访问了,对应的名字是pb/master,你可以将它合并到自己的某个分支,或者切换到这个分支,看看有些什么有趣的更新
从远程仓库抓取数据gitfetch/pull
gitfetch用法
正如之前所看到的,可以用下面的命令从远程仓库抓取数据到本地:
用法:
gitfetch[remote-name]//拉取[remote-name]所有的更新,但不合并
如:
gitfetchorigin
此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。
运行完成后,你就可以在本地访问该远程仓库中的所有分支,将其中某个分支合并到本地,或者只是取出某个分支,一探究竟.
如果是克隆了一个仓库,此命令会自动将远程仓库归于origin名下。
所以,gitfetchorigin会抓取从你上次克隆以来别人上传到此远程仓库中的所有更新(或是上次fetch以来别人提交的更新)。
有一点很重要,需要记住,fetch命令只是将远端的数据拉到本地仓库,并不自动合并到当前工作分支,只有当你确实准备好了,才能手工合并
gitpull用法
用法:
gitpull[remote-name][跟踪远程分支A的本地分支A]//在处于任何分支下,会将远程分支A的更新,直接合并到本地A分支上去
gitpull//前提是现在所在的分支为跟踪分支,也就是有一个对应的远程分支的本地分支,如本地master分支
如:
gitpullorigin[跟踪了某远程分支A的本地分支A]//会将远程分支A的更新,直接合并到本地A分支上去
在本地master分支上:
gitpull//将远程master分支拉取下来,并合并到当前的跟踪分支master上
如果设置了某个分支用于跟踪某个远端仓库的分支,可以使用gitpull命令自动抓取数据下来,然后将远端分支自动合并到本地仓库中当前分支。
在日常工作中我们经常这么用,既快且好。
实际上,默认情况下gitclone命令本质上就是自动创建了本地的master分支用于跟踪远程仓库中的master分支(假设远程仓库确实有master分支)。
所以一般我们运行gitpull,目的都是要从原始克隆的远端仓库中抓取数据后,合并到工作目录中当前分支
个人总结:
比如两个人同时在master分支上工作
一个1人修改了A文件,提交后,push到服务器,gitpushoriginmaster:
master,
此时另一2人也修改了A文件的同一个地方,提交后并未上传到服务器,1)此时他gitfetchorigin,这个时候会拉取服务器上的所有更新数据,但是并不合并,这个时候gitcheckoutorigin/master可以看到1人提交的更新,再gitcheckoutmaster,发现自己的本地分支master中并未此更新,这个时候可以再master分支下执行gitmergeorigin/master,自己的本地分支会合并服务器上;2)也可以直接不用gitfetchorigin直接用gitpullorigin拉取服务器更新,并合并,
同理
比如两个人同时在origin/s分支上开始建立本地分支1s,2s工作
一个1人修改了A文件,提交后,push到服务器,gitpushorigin1s:
s,
此时另一2人也修改了A文件的同一个地方,提交后并未上传到服务器,1)此时他gitfetchorigin,这个时候会拉取服务器上的所有更新数据,但是并不合并,这个时候gitcheckoutorigin/s可以看到1人提交的更新,再gitcheckout1s,发现自己的本地分支1s中并未此更新,这个时候可以再1s分支下执行gitmergeorigin/s,自己的本地分支会合并服务器上s分支;此时,1人如果在gitfetchorigin,会把2人的修改更新到自己仓库的origin/s上去,这个时候他需要再gitmergeorigin/s才能将2人的更新合并到自己的2s分支上。
重要概念:
跟踪分支
注意,本地的master分支和origin/master分支是有对应关系的,本地master更新提交服务器后,origin/master也会移动
-----------------------------------------------------------------------------
-----------AddV1.120140928Start
创建跟踪分支方法:
1:
gitcheckout--trackorigin/serverfix(会自动创建一个本地serverfix跟踪分支,可pull可push)
2:
gitcheckout--track(xx)origin/serverfix(会创建一个本地xx跟踪分支,可pull可push)
3:
gitcheckout-bxxorigin/serverfix会创建一个本地xx跟踪分支,可pull
-----------AddV1.120140928End
-----------------------------------------------------------------------------
本地分支推送到远程gitpush
用法:
gitpush[remote-name][branch-name];//将本地[branch-name]分支更新到远程分支中去,若无对应远程分支则以branch-name建立一个远程分支
gitpush[remote-name][branch-name]:
[remote-branch-name]//将本地分支更新到新建立的[remote-branch-name]远程分支中去,注意[remote-branch-name]是远程分支名,且要去掉[remote-name],如origin/s要写为s:
gitpushorigins:
s
注意,上面两种方法生成的remote-branch-name和本地的branch-name有push的关系,也就是,本地branch-name每次执行gitpush会自动的push到[remote-branch-name]上去,但是这二者不一定有pull关系
gitpush//这种用法是将有pull关系的本地分支更新到与之存在pull关系的远程分支中,下面专门讲到
将本地分支[branch-name]推送到[remote-name]服务器上的[remote-branch-name]分支上,本地的其他分支不会推送同一时刻没有其他人在推数据,这条命令才会如期完成任务
如果要把本地的master分支推送到origin服务器上(再次说明下,克隆操作会自动使用默认的master和origin名字),可以运行下面的命令
$gitpushoriginmaster
只有在所克隆的服务器上有写权限,或者同一时刻没有其他人在推数据,这条命令才会如期完成任务。
如果
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Git 服务 整理 总结 超群
![提示](https://static.bdocx.com/images/bang_tan.gif)