Git概述+常用命令解说.docx
《Git概述+常用命令解说.docx》由会员分享，可在线阅读，更多相关《Git概述+常用命令解说.docx（12页珍藏版）》请在冰豆网上搜索。
Git概述+常用命令解说
Git常用命令解说
1.Git概念
1.1.Git库中由三部分组成
Git仓库就是那个.git目录，其中存放的是我们所提交的文档索引内容，Git可基于文档索引内容对其所管理的文档进行内容追踪，从而实现文档的版本控制。
.git目录位于工作目录内。
1）工作目录：
用户本地的目录；
2）Index（索引）：
将工作目录下所有文件（包含子目录）生成快照，存放到一个临时的存储区域，Git称该区域为索引。
3）仓库：
将索引通过commit命令提交至仓库中，每一次提交都意味着版本在进行一次更新。
1.2.使用Git时的初始化事项
1.2.1.Git初始化配置
1）配置使用git仓库的人员姓名
gitconfig--globaluser.name"YourNameComesHere"
2）配置使用git仓库的人员email
gitconfig--globaluser.emailyou@
1.2.2.Git文档忽略机制
工作目录中有一些文件是不希望接受Git管理的，譬如程序编译时生成的中间文件等等。
Git提供了文档忽略机制，可以将工作目录中不希望接受Git管理的文档信息写到同一目录下的.gitignore文件中。
例如：
工作目录下有个zh目录，如果不想把它加入到Git管理中，则执行：
echo“zh”>.gitignore
gitadd.
有关gitignore文件的诸多细节知识可阅读其使用手册：
mangitignore
1.3.Git与Repo的比较
Git操作一般对应一个仓库，而Repo操作一般对应一个项目，即一个项目会由若干仓库组成。
例如，在操作整个Recket项目时使用Repo，而操作其中的某个仓库时使用Git。
在包含隐藏目录.git的目录下执行git操作。
2.Githelp
Githelp获取git基本命令
（如果要知道某个特定命令的使用方法，例如：
使用Githelpclone，来获取gitclone的使用方法）
3.Git本地操作基本命令
3.1.Gitinit
或者使用gitinit-db。
创建一个空的Git库。
在当前目录中产生一个.git的子目录。
以后，所有的文件变化信息都会保存到这个目录下，而不像CVS那样，会在每个目录和子目录下都创建一个CVS目录。
在.git目录下有一个config文件，可以修改其中的配置信息。
3.2.Gitadd
将当前工作目录中更改或者新增的文件加入到Git的索引中，加入到Git的索引中就表示记入了版本历史中，这也是提交之前所需要执行的一步。
可以递归添加，即如果后面跟的是一个目录作为参数，则会递归添加整个目录中的所有子目录和文件。
例如：
gitadddir1（添加dir1这个目录，目录下的所有文件都被加入）
Gitaddf1f2（添加f1，f2文件）
gitadd.（添加当前目录下的所有文件和子目录）
3.3.Gitrm
从当前的工作目录中和索引中删除文件。
可以递归删除，即如果后面跟的是一个目录做为参数，则会递归删除整个目录中的所有子目录和文件。
例如：
gitrm–r*（进入某个目录中，执行此语句，会删除该目录下的所有文件和子目录）
gitrmf1（删除文件f1，包含本地目录和index中的此文件记录）
gitrm--achedf1（删除文件f1，不会删除本地目录文件，只删除index中的文件记录；将已经gitadd的文件remove到cache中,这样commit的时候不会提交这个文件,适用于一下子添加了很多文件,却又想排除其中个别几个文件的情况.）
3.4.Gitcommit
提交当前工作目录的修改内容。
直接调用gitcommit命令，会提示填写注释。
通过如下方式在命令行就填写提交注释：
gitcommit-m"Initialcommitofgittutorreposistory"。
注意，和CVS不同，git的提交注释必须不能为空，否则就会提交失败。
gitcommit还有一个-a的参数，可以将那些没有通过gitadd标识的变化一并强行提交，但是不建议使用这种方式。
每一次提交，git就会为全局代码建立一个唯一的commit标识代码，用户可以通过gitreset命令恢复到任意一次提交时的代码。
gitcommit–-amend–m“message”（在一个commitid上不断修改提交的内容）
3.5.Gitstatus
查看版本库的状态。
可以得知哪些文件发生了变化，哪些文件还没有添加到git库中等等。
建议每次commit前都要通过该命令确认库状态。
最常见的误操作是，修改了一个文件，没有调用gitadd通知git库该文件已经发生了变化就直接调用commit操作，从而导致该文件并没有真正的提交。
这时如果开发者以为已经提交了该文件，就继续修改甚至删除这个文件，那么修改的内容就没有通过版本管理起来。
如果每次在提交前，使用gitstatus查看一下，就可以发现这种错误。
因此，如果调用了gitstatus命令，一定要格外注意那些提示为“Changedbutnotupdated:
”的文件。
这些文件都是与上次commit相比发生了变化，但是却没有通过gitadd标识的文件。
3.6.Gitlog
查看历史日志，包含每次的版本变化。
每次版本变化对应一个commitid。
Gitlog-1
-1的意思是只显示一个commit，如果想显示5个，就-5。
不指定的话，gitlog会从该commit一直往后显示。
Gitlog--stat–summary（显示每次版本的详细变化）
在项目日志信息中，每条日志的首行（就是那一串字符）为版本更新提交所进行的命名，我们可以将该命名理解为项目版本号。
项目版本号应该是唯一的，默认由Git自动生成，用以标示项目的某一次更新。
如果我们将项目版本号用作git-show命令的参数，即可查看该次项目版本的更新细节。
例如：
1）Gitlog
2）Gitshow
实际上，上述命令并非是真正的进行版本号自定义，只是制造了一个tag对象而已，这在进行项目版本对外发布时比较有用。
3.7.Gitmerge
把服务器上下载下来的代码和本地代码合并。
或者进行分支合并。
例如：
当前在master分支上，若想将分支dev上的合并到master上，则gitmergedev
注意：
gitmergenov/eclair_eocket（是将服务器git库的eclair_eocket分支合并到本地分支上）
gitrebasenov/eclair_eocket（是将服务器git库的eclair_eocket分支映射到本地的一个临时分支上，然后将本地分支上的变化合并到这个临时分支，然后再用这个临时分支初始化本地分支）
3.8.Gitdiff
把本地的代码和index中的代码进行比较，或者是把index中的代码和本地仓库中的代码进行比较。
1）Gitdiff
比较工作目录和Index中的代码。
2）Gitdiff--cached
比较index和本地仓库中的代码。
3.9.Gitcheckout
3.9.1.切换到分支
1）创建一个新分支，并切换到该分支上
Gitcheckout–b新分支名
2）切换到某个已经建立的本地分支local_branch
Gitcheckoutlocal_branch
（使用cat.git/HEAD后，显示refs:
refs/heads/local_branch）
3）切换到服务器上的某个分支remote_branch
Gitcheckoutremote_branch
（远程分支remote_branch可以通过gitbranch–r列出）
4）切换到某个commitid
Gitcheckoutcommit_id
（使用cat.git/HEAD后，显示commit_id）
5）切换到某个tag
Gitcheckouttag
（使用cat.git/HEAD后，显示tag）
注意：
除了1）和2）外，其余三种都只是切换到了一个临时的（nobranch）状态（thisheadisdetached），这时用gitbranch可以看到处于（nobranch）上，cat.git/HEAD看到指向相应的commitid。
这个（nobranch）只是临时存在的，并不是一个真正建立的branch。
如果此时执行2），则这个（nobranch）就自动消失了；如果执行1），则创建新分支newbranch，并把这个（nobranch）挂到这个新分支上，此时cat.git/refs/heads/new_branch可以看到已经指向了刚才那个commitid。
3.9.2.用已有分支初始化新分支
执行下面的命令，在切换到某个已经建立的localbranch或者某个remotebranch或者某个commitid或者某个tag的同时，创建新分支new_branch，并且挂到这个新分支上。
1）切换到某个已经建立的本地分支local_branch，并且使用此分支初始化一个新分支new_branch。
gitcheckout–bnew_branchlocal_branch
2）切换到某个远程分支remote_branch，并且用此分支初始化一个新分支new_branch。
Gitcheckout–bnew_branchremote_branch
3）切换到某个commitid，并建立新分支new_branch
Gitcheckout–bnew_branchcommit_id
4）切换到某个tag，并建立新分支new_branch
Gitcheckout–bnew_branchtag
3.9.3.还原代码
例如“gitcheckoutapp/model/user.rb”就会将user.rb文件从上一个已提交的版本中更新回来，未提交的工作目录中的内容全部会被覆盖。
3.10.Git-ls-files
查看当前的git库中有那些文件。
3.11.Gitmv
重命名一个文件、目录或者链接。
例如：
Gitmvhelloworld.chelloworld1.c（把文件helloworld.c重命名为helloworld1.c）
3.12.Gitbranch
3.12.1.总述
在git版本库中创建分支的成本几乎为零，所以，不必吝啬多创建几个分支。
当第一次执行gitinit时，系统就会创建一个名为“master”的分支。
而其它分支则通过手工创建。
下面列举一些常见的分支策略：
创建一个属于自己的个人工作分支，以避免对主分支master造成太多的干扰，也方便与他人交流协作；
当进行高风险的工作时，创建一个试验性的分支；
合并别人的工作的时候，最好是创建一个临时的分支用来合并，合并完成后再“fetch”到自己的分支。
对分支进行增、删、查等操作。
注意：
分支信息一般在.git/refs/目录下，其中heads目录下为本地分支，remotes为对应服务器上的分支，tags为标签。
3.12.2.查看分支
gitbranch列出本地git库中的所有分支。
在列出的分支中，若分支名前有*，则表示此分支为当前分支。
gitbranch–r列出服务器git库的所有分支。
（可以继续使用命令“gitcheckout-b本地分支名服务器分支名”来获取服务器上某个分支的代码文件）。
3.12.3.查看当前在哪个分支上
cat.git/HEAD
3.12.4.创建一个分支
1）gitbranch分支名
虽然创建了分支，但是不会将当前工作分支切换到新创建的分支上，因此，还需要命令“gitcheckout分支名”来切换，
2）gitchecout–b分支名
不但创建了分支，还将当前工作分支切换到了该分支上。
3.12.5.切换到某个分支：
gitcheckout分支名
切换到主分支：
gitcheckoutmaster
3.12.6.删除分支
gitbranch–D分支名
注意：
删除后，发生在该分支的所有变化都无法恢复。
强制删除此分支。
3.12.7.比较两个分支上的文件的区别
gitdiffmaster分支名（比较主分支和另一个分支的区别）
3.12.8.查看分支历史
git-show-branch（查看当前分支的提交注释及信息）
git-show-branch-all（查看所有分支的提交注释及信息）例如：
*[dev]d2
!
[master]m2
--
*[dev]d2
*[dev^]d1
*[dev~2]d0
*+[master]m2
在上述例子中，“--”之上的两行表示有两个分支dev和master，且dev分支上最后一次提交的日志是“d2”,master分支上最后一次提交的日志是“m2”。
“--”之下的几行表示了分支演化的历史，其中dev表示发生在dev分支上的最后一次提交，dev^表示发生在dev分支上的倒数第二次提交。
dev~2表示发生在dev分支上的倒数第三次提交。
3.12.9.查看当前分支的操作记录
gitwhatchanged
3.12.10.合并分支
法一：
gitmerge“注释”合并的目标分支合并的来源分支
如果合并有冲突，git会有提示。
例如：
gitcheckoutmaster（切换到master分支）
gitmergeHEADdev~2（合并master分支和dev~2分支）或者：
gitmergemasterdev~2
法二：
gitpull合并的目标分支合并的来源分支
例如:
gitcheckoutmaster（切换到master分支）
gitpull.dev~2（合并当前分支和dev~2分支）
3.13.Gitrebase
一般在将服务器最新内容合并到本地时使用，例如：
在版本C时从服务器上获取内容到本地，修改了本地内容，此时想把本地修改的内容提交到服务器上；但发现服务器上的版本已经变为G了，此时就需要先执行Gitrebase，将服务器上的最新版本合并到本地。
例如：
用下面两幅图解释会比较清楚一些，rebase命令执行后，实际上是将分支点从C移到了G，这样分支也就具有了从C到G的功能。
3.14.Gitreset
库的逆转与恢复除了用来进行一些废弃的研发代码的重置外，还有一个重要的作用。
比如我们从远程clone了一个代码库，在本地开发后，准备提交回远程。
但是本地代码库在开发时，有功能性的commit，也有出于备份目的的commit等等。
总之，commit的日志中有大量无用log，我们并不想把这些log在提交回远程时也提交到库中。
因此，就要用到gitreset。
gitreset的概念比较复杂。
它的命令形式：
gitreset[--mixed|--soft|--hard][]
命令的选项：
--mixed这个是默认的选项。
如gitreset[--mixed]dev^（dev^的定义可以参见2.6.5）。
它的作用仅是重置分支状态到dev1^,但是却不改变任何工作文件的内容。
即，从dev1^到dev1的所有文件变化都保留了，但是dev1^到dev1之间的所有commit日志都被清除了，而且，发生变化的文件内容也没有通过gitadd标识，如果您要重新commit，还需要对变化的文件做一次gitadd。
这样，commit后，就得到了一份非常干净的提交记录。
（回退了index和仓库中的内容）
--soft相当于做了gitreset–mixed，后，又对变化的文件做了gitadd。
如果用了该选项，就可以直接commit了。
（回退了仓库中的内容）
--hard这个命令就会导致所有信息的回退，包括文件内容。
一般只有在重置废弃代码时，才用它。
执行后，文件内容也无法恢复回来了。
（回退了工作目录、index和仓库中的内容）
例如：
切换到使用的分支上；
gitresetHEAD^回退第一个记录
gitresetHEAD~2回退第二个记录
如果想把工作目录下的文件也回退，则使用gitreset--hardHEAD^回退第一个记录
gitreset--hardHEAD~2回退第二个记录
还可以使用如下方法：
将当前的工作目录完全回滚到指定的版本号，假设如下图，我们有A-G五次提交的版本，其中C的版本号是bbaf6fb5060b4875b18ff9ff637ce118256d6f20，我们执行了'gitresetbbaf6fb5060b4875b18ff9ff637ce118256d6f20'那么结果就只剩下了A-C三个提交的版本
3.15.Gitrevert
还原某次对版本的修改，例如：
gitrevertcommit_id（其中commit_id为commit代码时生成的一个唯一表示的字符串）
例如：
（3.6中）gitrevertdfb02e6e4f2f7b573337763e5c0013802e392818（执行此操作，则还原上一次commit的操作）
3.16.Gitconfig
利用这个命令可以新增、更改Git的各种设置，例如“gitconfigbranch.master.remoteorigin”就将master的远程版本库设置为别名叫做origin版本库。
3.17.Gitshow
显示对象的不同类型。
3.18.Gittag
创建、列出、删除或者验证一个标签对象（使用GPG签名的）。
可以将某个具体的版本打上一个标签，这样就不需要记忆复杂的版本号哈希值字符串了，例如你可以使用“gittagrevert_versionbbaf6fb5060b4875b18ff9ff637ce118256d6f20”来标记这个被你还原的版本，那么以后你想查看该版本时，就可以使用revert_version标签名，而不是哈希值了。
4.Git服务器操作命令（与服务器交互）
4.1.Gitclone
取出服务器的仓库的代码到本地建立的目录中（与服务器交互）
通过gitclone获取远端git库后，.git/config中的开发者信息不会被一起clone过来。
仍然需要为本地库的.git/config文件添加开发者信息。
此外，开发者还需要自己添加.gitignore文件。
通过gitclone获取的远端git库，只包含了远端git库的当前工作分支。
如果想获取其它分支信息，需要使用“gitbranch–r”来查看，如果需要将远程的其它分支代码也获取过来，可以使用命令“gitcheckout-b本地分支名远程分支名”，其中，远程分支名为“gitbranch–r”所列出的分支名，一般是诸如“origin/分支名”的样子。
如果本地分支名已经存在，则不需要“-b”参数。
例如：
4.2.Gitpull
从服务器的仓库中获取代码，和本地代码合并。
（与服务器交互，从服务器上下载最新代码，等同于：
Gitfetch+Gitmerge）
从其它的版本库（既可以是远程的也可以是本地的）将代码更新到本地，例如：
“gitpulloriginmaster”就是将origin这个版本库的代码更新到本地的master主分支。
gitpull可以从任意一个git库获取某个分支的内容。
用法如下：
gitpullusername@ipaddr:
远端repository名远端分支名本地分支名。
这条命令将从远端git库的远端分支名获取到本地git库的一个本地分支中。
其中，如果不写本地分支名，则默认pull到本地当前分支。
需要注意的是，gitpull也可以用来合并分支。
和gitmerge的作用相同。
因此，如果你的本地分支已经有内容，则gitpull会合并这些文件，如果有冲突会报警。
例如：
4.3.Gitpush
将本地commit的代码更新到远程版本库中，例如“gitpushorigin”就会将本地的代码更新到名为orgin的远程版本库中。
gitpush和gitpull正好想反，是将本地某个分支的内容提交到远端某个分支上。
用法：
gitpushusername@ipaddr:
远端repository名本地分支名远端分支名。
这条命令将本地git库的一个本地分支push到远端git库的远端分支名中。
需要格外注意的是，gitpush好像不会自动合并文件。
因此，如果gitpush时，发生了冲突，就会被后push的文件内容强行覆盖，而且没有什么提示。
这在合作开发时是很危险的事情。
例如：
4.4.Gitfetch
从服务器的仓库中下载代码。
（与服务器交互，从服务器上下载最新代码）
相当于从远程获取最新版本到本地，不会自动merge，比Gitpull更安全些。
使用此方法来获取服务器上的更新。
例如：
如果使用gitcheckoutnov/eclair_rocket（nov/eclair_rocket为服务器上的分支名），则是获取上次使用gitfetch命令时从服务器上下载的代码；如果先使用gitfetch，再使用gitcheckoutnov/eclair_rocket，则是先从服务器上获取最新的更新信息，然后从服务器上下载最新的代码。
升级会员 