Git服务整理总结王超群.docx

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--help

比如，要学习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

只有在所克隆的服务器上有写权限，或者同一时刻没有其他人在推数据，这条命令才会如期完成任务。

如果