git使用具体介绍
1.1. Git库中由三部分组成
Git 仓库就是那个.git 文件夹,当中存放的是我们所提交的文档索引内容,Git 可基于文档索引内容对其所管理的文档进行内容追踪,从而实现文档的版本号控制。.git文件夹位于工作文件夹内。
1) 工作文件夹:用户本地的文件夹;
2) Index(索引):将工作文件夹下全部文件(包括子文件夹)生成快照,存放到一个暂时的存储区域,Git 称该区域为索引。
3) 仓库:将索引通过commit命令提交至仓库中,每一次提交都意味着版本号在进行一次更新。
![clip_image002 clip_image002](http://img1.51cto.com/attachment/201102/10/2712776_1297350409WAxs.jpg)
1.2. 使用Git时的初始化事项
1.2.1. Git初始化配置
1) 配置使用git仓库的人员姓名
git config --global user.name "Your Name Comes Here"
2) 配置使用git仓库的人员email
git config --global user.email you@yourdomain.example.com
1.2.2. Git文档忽略机制
工作文件夹中有一些文件是不希望接受Git 管理的,譬如程序编译时生成的中间文件等等。Git 提供了文档忽略机制,能够将工作文件夹中不希望接受Git 管理的文档信息写到同一文件夹下的.gitignore 文件里。
比如:工作文件夹下有个zh文件夹,假设不想把它增加到Git管理中,则运行:
echo “zh” > .gitignore
git add .
有关gitignore 文件的诸多细节知识可阅读其使用手冊:man gitignore
1.3. Git与Repo的比較
Git操作一般相应一个仓库,而Repo操作一般相应一个项目,即一个项目会由若干仓库组成。
比如,在操作整个Recket项目时使用Repo,而操作当中的某个仓库时使用Git。在包括隐藏文件夹.git的文件夹下运行git操作。
2. Git help
Git help 获取git基本命令
(假设要知道某个特定命令的用法,比如:使用Git help clone,来获取git clone的用法)
3. Git本地操作基本命令
3.1. Git init
或者使用git init-db。
创建一个空的Git库。在当前文件夹中产生一个.git 的子文件夹。以后,全部的文件变化信息都会保存到这个文件夹下,而不像CVS那样,会在每一个文件夹和子文件夹下都创建一个CVS文件夹。
在.git文件夹下有一个config文件,能够改动当中的配置信息。
3.2. Git add
将当前工作文件夹中更改或者新增的文件增加到Git的索引中,增加到Git的索引中就表示记入了版本号历史中,这也是提交之前所须要运行的一步。
能够递归加入,即假设后面跟的是一个文件夹作为參数,则会递归加入整个文件夹中的全部子文件夹和文件。比如:
git add dir1 ( 加入dir1这个文件夹,文件夹下的全部文件都被加入 )
Git add f1 f2 ( 加入f1,f2文件)
git add . ( 加入当前文件夹下的全部文件和子文件夹 )
3.3. Git rm
从当前的工作文件夹中和索引中删除文件。
能够递归删除,即假设后面跟的是一个文件夹做为參数,则会递归删除整个文件夹中的全部子文件夹和文件。比如:
git rm –r * (进入某个文件夹中,运行此语句,会删除该文件夹下的全部文件和子文件夹)
git rm f1 (删除文件f1,包括本地文件夹和index中的此文件记录)
git rm --ached f1 (删除文件f1,不会删除本地文件夹文件,仅仅删除index中的文件记录;将已经git add的文件remove到cache中,这样commit的时候不会提交这个文件, 适用于一下子加入了非常多文件, 却又想排除当中个别几个文件的情况.)
3.4. Git commit
提交当前工作文件夹的改动内容。
直接调用git commit命令,会提示填写凝视。通过例如以下方式在命令行就填写提交凝视:git commit -m "Initial commit of gittutor reposistory"。 注意,和CVS不同,git的提交凝视必须不能为空,否则就会提交失败。
git commit另一个 -a的參数,能够将那些没有通过git add标识的变化一并强行提交,可是不建议使用这样的方式。
每一次提交,git就会为全局代码建立一个唯一的commit标识代码,用户能够通过git reset命令恢复到随意一次提交时的代码。
git commit –-amend –m “message” (在一个commit id上不断改动提交的内容)
3.5. Git status
查看版本号库的状态。能够得知哪些文件发生了变化,哪些文件还没有加入到git库中等等。 建议每次commit前都要通过该命令确认库状态。
最常见的误操作是, 改动了一个文件, 没有调用git add通知git库该文件已经发生了变化就直接调用commit操作, 从而导致该文件并没有真正的提交。这时假设开发人员以为已经提交了该文件,就继续改动甚至删除这个文件,那么改动的内容就没有通过版本号管理起来。假设每次在 提交前,使用git status查看一下,就能够发现这样的错误。因此,假设调用了git status命令,一定要格外注意那些提示为 “Changed but not updated:”的文件。 这些文件都是与上次commit相比发生了变化,可是却没有通过git
add标识的文件。
3.6. Git log
查看历史日志,包括每次的版本号变化。每次版本号变化相应一个commit id。
Git log -1
-1的意思是仅仅显示一个commit,假设想显示5个,就-5。不指定的话,git log会从该commit一直往后显示。
Git log --stat –summary (显示每次版本号的具体变化)
在项目日志信息中,每条日志的首行(就是那一串字符)为版本号更新提交所进行的命名,我们能够将该命名理解为项目版本号号。项目版本号号应该是唯一的,默认由 Git 自己主动生成,用以标示项目的某一次更新。假设我们将项目版本号号用作git-show 命令的參数,就可以查看该次项目版本号的更新细节。比如:
1) Git log
2)Git show
实际上,上述命令并不是是真正的进行版本号号自己定义,仅仅是制造了一个tag对象而已,这在进行项目版本号对外公布时比較实用。
3.7. Git merge
把server上下载下来的代码和本地代码合并。或者进行分支合并。
比如:当前在master分支上,若想将分支dev上的合并到master上,则git merge dev
注意:git merge nov/eclair_eocket (是将servergit库的eclair_eocket分支合并到本地分支上)
git rebase nov/eclair_eocket (是将servergit库的eclair_eocket分支映射到本地的一个暂时分支上,然后将本地分支上的变化合并到这个暂时分支,然后再用这个暂时分支初始化本地分支)
3.8. Git diff
把本地的代码和index中的代码进行比較,或者是把index中的代码和本地仓库中的代码进行比較。
1) Git diff
比較工作文件夹和Index中的代码。
2) Git diff - - cached
比較index和本地仓库中的代码。
3.9. Git checkout
3.9.1. 切换到分支
1) 创建一个新分支,并切换到该分支上
Git checkout –b 新分支名
2)切换到某个已经建立的本地分支local_branch
Git checkout local_branch
(使用cat .git/HEAD后,显示refs:refs/heads/ local_branch)
3) 切换到server上的某个分支remote_branch
Git checkout remote_branch
(远程分支remote_branch能够通过 git branch –r 列出)
4) 切换到某个commit id
Git checkout commit_id
(使用cat .git/HEAD后,显示commit_id)
5) 切换到某个tag
Git checkout tag
(使用cat .git/HEAD后,显示tag)
注意: 除了1)和2)外,其余三种都仅仅是切换到了一个暂时的( no branch )状态 (this head is detached),这时用 git branch 能够看到处于(no branch)上, cat .git/HEAD 看到指向对应的commit id。 这个(no branch)仅仅是暂时存在的,并非一个真正建立的branch。 假设此时运行2),则这个(no branch)就自己主动消失了;假设运行1), 则创建新分支 new branch,并把这个(no branch)挂到这个新分支上,此时cat
.git/refs/heads/new_branch 能够看到已经指向了刚才那个commit id。
3.9.2. 用已有分支初始化新分支
运行以下的命令,在切换到某个已经建立的local branch或者某个remote branch或者某个commit id 或者某个tag的同一时候,创建新分支new_branch,而且挂到这个新分支上。
1) 切换到某个已经建立的本地分支local_branch,而且使用此分支初始化一个新分支new_branch。
git checkout –b new_branch local_branch
2) 切换到某个远程分支remote_branch,而且用此分支初始化一个新分支new_branch。
Git checkout –b new_branch remote_branch
3) 切换到某个commit id,并建立新分支new_branch
Git checkout –b new_branch commit_id
4) 切换到某个tag,并建立新分支new_branch
Git checkout –b new_branch tag
3.9.3. 还原代码
比如 “git checkout app/model/user.rb” 就会将user.rb文件从上一个已提交的版本号中更新回来,未提交的工作文件夹中的内容所有会被覆盖。
3.10. Git-ls-files
查看当前的git库中有那些文件。
3.11. Git mv
重命名一个文件、文件夹或者链接。
比如:Git mv helloworld.c helloworld1.c (把文件helloworld.c 重命名为 helloworld1.c)
3.12. Git branch
3.12.1. 总述
在 git 版本号库中创建分支的成本差点儿为零,所以,不必吝啬多创建几个分支。当第一次运行git init时,系统就会创建一个名为“master”的分支。 而其他分支则通过手工创建。
以下列举一些常见的分支策略:
创建一个属于自己的个人工作分支,以避免对主分支 master 造成太多的干扰,也方便与他人交流协作;
当进行高风险的工作时,创建一个试验性的分支;
合并别人的工作的时候,最好是创建一个暂时的分支用来合并,合并完毕后再“fetch”到自己的分支。
对分支进行增、删、查等操作。
注意:分支信息一般在.git/refs/文件夹下,当中heads文件夹下为本地分支,remotes为相应server上的分支,tags为标签。
3.12.2. 查看分支
git branch 列出本地git库中的全部分支。在列出的分支中,若分支名前有*,则表示此分支为当前分支。
git branch –r 列出servergit库的全部分支。
(能够继续使用命令 “ git checkout -b 本地分支名 server分支名”来获取server上某个分支的代码文件)。
3.12.3. 查看当前在哪个分支上
cat .git/HEAD
3.12.4. 创建一个分支
1) git branch 分支名
尽管创建了分支,可是不会将当前工作分支切换到新创建的分支上,因此,还须要命令“git checkout 分支名” 来切换,
2) git checout –b 分支名
不但创建了分支,还将当前工作分支切换到了该分支上。
3.12.5. 切换到某个分支:git checkout 分支名
切换到主分支:git checkout master
3.12.6. 删除分支
git branch –D 分支名
注意: 删除后,发生在该分支的全部变化都无法恢复。强制删除此分支。
3.12.7. 比較两个分支上的文件的差别
git diff master 分支名 (比較主分支和还有一个分支的差别)
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. 查看当前分支的操作记录
git whatchanged
3.12.10. 合并分支
法一:
git merge “凝视” 合并的目标分支 合并的来源分支
假设合并有冲突,git会有提示。
比如:git checkout master (切换到master分支)
git merge HEAD dev~2 (合并master分支和dev~2分支)或者:git merge master dev~2
法二:
git pull 合并的目标分支 合并的来源分支
比如: git checkout master (切换到master分支)
git pull . dev~2(合并当前分支和dev~2分支)
3.13. Git rebase
一般在将server最新内容合并到本地时使用,比如:在版本号C时从server上获取内容到本地,改动了本地内容,此时想把本地改动的内容提交到server上;但发现server上的版本号已经变为G了,此时就须要先运行Git rebase,将server上的最新版本号合并到本地。比如:
用以下两幅图解释会比較清楚一些,rebase命令运行后,实际上是将分支点从C移到了G,这样分支也就具有了从C到G的功能。
3.14. Git reset
库的逆转与恢复除了用来进行一些废弃的研发代码的重置外,另一个关键的数据。比方我们从远程clone了一个代码库,在本地开发后,准备提交回远程。可是本地代码库在开发时,有功能性的commit,也有出于备份目的的commit等等。总之,commit的日志中有大量无用log,我们并不想把这些 log在提交回远程时也提交到库中。 因此,就要用到git reset。
git reset的概念比較复杂。它的命令形式:git reset [--mixed | --soft | --hard] [<commit-ish>]
命令的选项:
--mixed 这个是默认的选项。如git reset [--mixed] dev^(dev^的定义能够參见2.6.5)。它的作用仅是重置分支状态到dev1^, 可是却不改变不论什么工作文件的内容。即,从dev1^到dev1的全部文件变化都保留了,可是dev1^到dev1之间的全部commit日志都被清除了, 并且,发生变化的文件内容也没有通过git add标识,假设您要又一次commit,还须要对变化的文件做一次git add。 这样,commit后,就得到了一份很干净的提交记录。 (回退了index和仓库中的内容)
--soft相当于做了git reset –mixed,后,又对变化的文件做了git add。假设用了该选项, 就能够直接commit了。(回退了仓库中的内容)
--hard这个命令就会导致全部信息的回退, 包含文件内容。 一般仅仅有在重置废弃代码时,才用它。 运行后,文件内容也无法恢复回来了。(回退了工作文件夹、index和仓库中的内容)
比如:
切换到使用的分支上;
git reset HEAD^ 回退第一个记录
git reset HEAD~2 回退第二个记录
假设想把工作文件夹下的文件也回退,则使用git reset - - hard HEAD^ 回退第一个记录
git reset - - hard HEAD~2 回退第二个记录
还能够使用例如以下方法:
将当前的工作文件夹全然回滚到指定的版本号号,如果例如以下图,我们有A-G五次提交的版本号,当中C的版本号号是 bbaf6fb5060b4875b18ff9ff637ce118256d6f20,我们运行了'git reset bbaf6fb5060b4875b18ff9ff637ce118256d6f20'那么结果就仅仅剩下了A-C三个提交的版本号
3.15. Git revert
还原某次对版本号的改动,比如:git revert commit_id (当中commit_id为commit代码时生成的一个唯一表示的字符串)
比如:(3.6中)git revert dfb02e6e4f2f7b573337763e5c0013802e392818 (运行此操作,则还原上一次commit的操作)
3.16. Git config
利用这个命令能够新增、更改Git的各种设置,比如 “git config branch.master.remote origin” 就将master的远程版本号库设置为别名叫做origin版本号库。
3.17. Git show
显示对象的不同类型。
3.18. Git tag
创建、列出、删除或者验证一个标签对象(使用GPG签名的)。
能够将某个详细的版本号打上一个标签,这样就不须要记忆复杂的版本号号哈希值字符串了,比如你能够使用 “git tag revert_version bbaf6fb5060b4875b18ff9ff637ce118256d6f20” 来标记这个被你还原的版本号,那么以后你想查看该版本号时,就能够使用 revert_version标签名,而不是哈希值了。
4. Gitserver操作命令(与server交互)
4.1. Git clone
取出server的仓库的代码到本地建立的文件夹中(与server交互)
通过git clone获取远端git库后,.git/config中的开发人员信息不会被一起clone过来。仍然须要为本地库的.git/config文件加入开发人员信息。此外,开发人员还须要自己加入 . gitignore文件。
通过git clone获取的远端git库,仅仅包括了远端git库的当前工作分支。假设想获取其他分支信息,须要使用 “git branch –r” 来查看, 假设须要将远程的其他分支代码也获取过来,能够使用命令 “ git checkout -b 本地分支名 远程分支名”,当中,远程分支名为 “git branch –r” 所列出的分支名, 通常是诸如“origin/分支名”的样子。假设本地分支名已经存在, 则不须要“-b”參数。
比如:
4.2. Git pull
从server的仓库中获代替码,和本地代码合并。(与server交互,从server上下载最新代码,等同于: Git fetch + Git merge)
从其他的版本号库(既能够是远程的也能够是本地的)将代码更新到本地,比如:“git pull origin master ”就是将origin这个版本号库的代码更新到本地的master主分支。
git pull能够从随意一个git库获取某个分支的内容。使用方法例如以下:
git pull username@ipaddr:远端repository名远端分支名 本地分支名。这条命令将从远端git库的远端分支名获取到本地git库的一个本地分支中。当中,假设不写本地分支名,则默认pull到本地当前分支。
须要注意的是,git pull也能够用来合并分支。 和git merge的作用同样。 因此,假设你的本地分支已经有内容,则git pull会合并这些文件,假设有冲突会报警。
比如:
4.3. Git push
将本地commit的代码更新到远程版本号库中,比如 “git push origin”就会将本地的代码更新到名为orgin的远程版本号库中。
git push和git pull正好想反,是将本地某个分支的内容提交到远端某个分支上。使用方法: git pushusername@ipaddr:远端repository名本地分支名 远端分支名。这条命令将本地git库的一个本地分支push到远端git库的远端分支名中。
须要格外注意的是,git push好像不会自己主动合并文件。因此,假设git push时,发生了冲突,就会被后push的文件内容强行覆盖,并且没有什么提示。 这在合作开发时是非常危急的事情。
比如:
4.4. Git fetch
从server的仓库中下载代码。(与server交互,从server上下载最新代码)
相当于从远程获取最新版本号到本地,不会自己主动merge,比Git pull更安全些。
使用此方法来获取server上的更新。
比如:假设使用git checkout nov/eclair_rocket (nov/eclair_rocket为server上的分支名),则是获取上次使用git fetch命令时从server上下载的代码;假设先使用 git fetch ,再使用git checkout nov/eclair_rocket,则是先从server上获取最新的更新信息,然后从server上下载最新的代码。