安装后初始化配置
配置全局的用户名(--global此电脑所有git仓库都会使用该配置)
$ git config --global user.name "Your Name"
配置全局的邮箱地址(--global此电脑所有git仓库都会使用该配置)
$ git config --global user.email "email@example.com"
查看配置信息
$ git config --system --list ## 查看系统配置
$ git config --global --list ## 查看当前用户配置
$ git config --local --list ## 查看当前仓库配置
创建版本库
创建一个空目录作为版本库目录
$ mkdir learngit # 创建目录learngit(即为版本库)
$ cd learngit # 进入该目录
$ pwd # 查看路径
/Users/michael/learngit
初始化该目录,使其可以被git管理,此后该目录会出现一个.git目录(如果没有可能被隐藏了,可以用:ls -ah查看)
$ git init # 初始化该目录之后会出现以下提示
Initialized empty Git repository in /Users/michael/learngit/.git/
$ ls -ah # 查看当前目录文件,包括隐藏文件
在目录下面新建一个文件,用于做测试,内容随便
$ ls
readme.php
$ cat readme.php
Git is a version control system.
Git is free software.
将文件放入到仓库只需要两步
1). 告诉Git将要将要添加该文件到仓库(add后面可以跟多个文件用空格隔开,也可以跟目录,并且可以将文件多次分别add,只要在commit之前都算一次提交)
$ git add readme.txt
2). 将文件提交到仓库
$ git commit -m "wrote a readme file"
[master (root-commit) 74256b9] wrote a readme file
2 files changed, 6 insertions(+)
create mode 100644 reademe.php
create mode 100644 readme.php
==注意:每次修改,如果不用git add到暂存区,那就不会加入到commit中==
对文件进行修改,添加一个单词,然后通过命令查看状态
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
告诉我们文件被修改过了,但是还没有准备提交的修改
查看具体修改了哪些内容
$ git diff readme.php # 会显示出修改的内容信息
版本回退
查看所有的版本日志
$ git log # 如果需要精简到一行的信息加上参数 --pretty=oneline 即可
在Git中,用HEAD表示当前版本,也就是最新的提交1094adb...
(注意我的提交ID和你的肯定不一样),
上一个版本就是HEAD^,
上上一个版本就是HEAD^^,
当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
如下,回退到上一个版本,执行命令后用cat查看发现内容已经变了
$ git reset --hard HEAD^
如果我回到过去的版本了,随后又想恢复到原来的版本怎么办,只要命令框没有关闭,还可以找到原来的版本号,取前几位就可以,但是也不能太少,用以下命令
$ git reset --hard 3642b # 版本号写前几位就可以,但是也不能太短,能识别就行
但是如果手贱关闭了命令框,关闭了电脑,怎么办,回退版本后发现错了,还想回来怎么办
$ git reflog # 这个命令可以查看你所有操作命令的日志,当然里面是有版本号的了
工作区概念:就是你在本地电脑里能看到的目录
版本库概念:工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。
前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。
撤销更改
情况一:准备提交之前如果发现了错误(==add之前==)
- 一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
- 一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
- 总之,就是让这个文件回到最近一次git commit或git add时的状态。
$ git checkout -- readme.php
情况二:已经提交到暂存区了(==add之后commit之前==)
1). git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。
$ git reset HEAD readme.php
2). 此时就变为了情况一,暂存区没有了,但是工作区还有
$ git checkout -- readme.php
情况三:已经提交到了分支(==commit之后==)
可以采用版本回退的方法情况四:不仅提交到了分支,还推送到了远程版本库
那么恭喜你,本次撤销修改是不可能的了
删除文件
当你从本地删除了一个文件,可以有两种选择:
1). 确定要删除了,然后将分支中的文件也删除掉
$ git rm test.php
$ git commit -m "remove test.php"
2). 发现删错了,想要将其从分支恢复回来
$ git checkout -- test.php
远程仓库操作
添加远程仓库
[1]. 第一步:==创建SSH Key==。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:
$ ssh-keygen -t rsa -C "youremail@example.com"
注意:需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,密码没必要设置,如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对, ==id_rsa是私钥==,不能泄露出去,==id_rsa.pub是公钥==,可以放心地告诉任何人[2]. 第二步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:
然后,点“==Add SSH Key==”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容
==为什么GitHub需要SSH Key呢?==
因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
[3]. ==在github上新建空的版本库==
$ git remote add origin git@github.com:KeepFang/learngit.git
注意:要将KeepFang换成自己的github用户名,learngit换成自己的远程库名字添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。
[4]. 将本地内容推送到远程库
$ git push -u origin master # 将本地库内容推送到远程库
把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送到远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
从现在起,只要本地作了提交,就可以通过命令:
$ git push origin master
==SSH警告==
当你第一次使用Git的clone或者push命令连接GitHub时,会得到一个警告
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?
这是因为Git使用SSH连接,而SSH连接在第一次验证GitHub服务器的Key时,需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器,输入yes回车即可。Git会输出一个警告,告诉你已经把GitHub的Key添加到本机的一个信任列表里了:
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
==克隆远程库文件到本地==
git clone git@github.com:用户名/版本库名.git
你也许还注意到,GitHub给出的地址不止一个,还可以用https://github.com/michaellia...。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
分支
分支在实际中怎么用呢?团队合作开发一个项目,你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
1). 创建分支
$ git checkout -b dev # 创建分支dev并切换到该分支
等价于
$ git branch dev # 创建分支
$ git checkout dev # 切换分支
$ git branch # 列出所有分支,当前分支前面会标一个 * 号
2). 合并分支
$ git checkout master # 切换到主分支
$ git merge dev # 将dev分支与当前分支合并
$ git branch -d dev # 合并完成之后就可以删除dev分支了
$ git branch # 删除之后再次查看分支,发现只剩下master分支了
通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
$ git merge --no-ff -m "merge with no-ff" dev # 禁用fast forward快速合并模式,
## 合并分支时,加上--no-ff参数就可以用普通模式合并,
## 合并后的历史有分支,能看出来曾经做过合并,
## 而fast forward合并就看不出来曾经做过合并。
$ git log --graph --pretty=oneline --abbrev-commit # 然后再查看分支历史
3). 解决冲突
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。
合并之后,删除没用的分支
$ git log --graph --pretty=oneline --abbrev-commit # graph参数是查看分支合并图
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
bug分支
当你正在开发一个新功能的时候,突然有人反馈原先的项目存在一个bug,很自然想到新建一个分支来进行修复然后合并,但是现在你的工作还没完成,又不能提交,这时候就需要用到 ==保存现场== 功能
$ git stash # 将当前工作的现场储存起来
$ git status # 这时候再看发现工作区是干净的可以放心创建分支
1). 确定在哪个分支修复bug,就从哪个分支创建临时分支,假设是master
$ git checkout master # 切换到master分支
$ git checkout -b issue-101 # 创建并切换到bug分支
$ git add readme.txt
$ git commit -m "fix bug 101" # 模拟修复bug
$ git checkout master # 切换到主分支
$ $ git merge --no-ff -m "merged bug fix 101" issue-101 # 将bug分支与主分支合并
2). 修复bug后继续dev分支开发
$ git checkout dev # 继续返回dev写未完成的工作
$ git status # 此时工作区是干净的,那之前保存的现场在哪里呢
$ git stash list # 查看保存的工作现场
3).恢复之前的现场
$ git stash pop # 恢复现场并删除该stash
$ git stash list # 再次查看发现,已经没有stash了
等价于
$ git stash apply # 恢复现场
$ git stash drop # 删除stash
$ git stash list # 再次查看发现,已经没有stash了
还可以多次stash,恢复指定现场
$ git stash apply stash@{0} # 恢复指定编号的现场
feature分支(新功能分支)
开发一个新功能,最好新建一个分支,至于怎么新建分支这个上面已经有概述
特殊情况:如果需要丢弃一个未合并的分支
$ git branch -D feature-vulcan # 如果要强制丢弃一个未合并的分支需要用大写的D参数
多人协作
1). 查看远程仓库信息
$ git remote # 查看远程仓库信息
$ git remote -v # 查看远程仓库详细信息
2). 推送分支到远程库
$ git push origin dev # 推送当前分支到指定的远程分支
但是,==并不是一定要把本地分支往远程推送==,那么,哪些分支需要推送,哪些不需要呢?
master分支是主分支,因此要时刻与远程同步;
dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!
3). 抓取分支
3.1. 模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆:
$ git clone git@github.com:用户名/仓库名.git # 从服务器上拉取项目到本地
$ git branch # 拉取下来之后本地默认只能看到一个master分支
3.2. 现在你的小伙伴要在dev分支上面进行开发了,于是他需要创建dev分支在本地
$ git checkout -b dev origin/dev # 创建=(远程)=的dev分支到本地
3.3. 现在就可以开发dev分支,并时不时提交到远程
$ git add env.txt # 模拟开发dev分支
$ git commit -m "add env"
$ git push origin dev # 提交分支到远程
3.4. 如果多个人都在开发dev分支呢,为了保证一致性,需要先更新再提交
$ git add env.txt # 模拟你的提交
$ git commit -m "add new env"
$ git push origin dev # 假设你的队友已经修改过dev分支了,那么会推送失败
$ git pull # 需要先pull更新代码为最新,可能还会报错,
## 因为没有建立本地dev与远程dev分支的直接链接
$ git branch --set-upstream-to=origin/dev dev # 按照报错信息建立链接
$ git pull # 这时候返回pull成功,但是可能你和队友修改了同样地方会提示有冲突
$ git commit -m "fix env conflict" # 解决冲突后,先提交,然后push
$ git push origin dev# 修复冲突后再次推送
rebase(变基:说白了就是美化分支线)
多人协作,分支很混乱,如果有强迫症非要整理成一条线呢
1). 原来分支图是这样
$ git log --graph --pretty=oneline --abbrev-commit # 查看分支线
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
* e5e69f1 Merge branch 'dev'
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
...
注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello,本地分支比远程分支快两个提交。2). 当我们再次提交,很不幸,有个人已经提前提交了,出现了冲突,按照习惯先pull一下
$ git push origin master # 假设失败了
$ git pull # 先pull一下
$ git status # 查看状态
$ git log --graph --pretty=oneline --abbrev-commit # 再次查看分支线,发现分叉了,
## 但是现在继续提交时完全没有问题的,就是线不好看
$ git rebase # 用命令美化线为一条
$ git log --graph --pretty=oneline --abbrev-commit # 再次查看分支线,发现变为了一条直线
$ git push origin master # 最后提交分支到远程
==rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比==。
标签管理
tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。例如:v1.21). 创建标签
$ git branch # 查看分支
$ git checkout master # 切换到分支
$ git tag v1.0 # 打标签
$ git tag # 查看所有标签
如果前面的忘记打标签现在要补上怎么办
$ git log --pretty=oneline --abbrev-commit # 找到对应版本号
$ git tag v0.9 f52c633 # 指定版本号打标签
$ git tag # 查看标签
标签不是按时间顺序列出,而是按字母排序的。可以用git show <tagname>查看标签信息
$ git show v0.9 # 查看标签信息
$ git tag -a v0.1 -m "version 0.1 released" 1094adb # 要想带上标签说明,可以用-m参数
$ git show v0.1 # 这个命令同样可以查看到标签的说明信息
2). 操作标签
删除本地标签
$ git tag -d v0.1
推送某个标签到远程
$ git push origin v1.0
一次性推送全部尚未推送到远程的本地标签
$ git push origin --tags
删除远程标签
$ git tag -d v0.9 # 先从本地删除
$ git push origin :refs/tags/v0.9 # 删除远程标签
Github上参与别人的开发
在GitHub上,可以任意Fork开源仓库;自己拥有Fork后的仓库的读写权限;
可以推送pull request给官方仓库来贡献代码。
使用国内的码云(gitee)
1). 先注册账号后配置公钥
2). 如果已经有了一个本地仓库,想要关联到码云
[1]. 首先在码云上面创建这个项目
[2]. 将本地库只与码云库关联
$ git remote add origin git@gitee.com:用户名/项目名.git
==如果在使用命令git remote add时报错,说明本地已经关联了一个远程库==
此时先查看远程库信息
$ git remote -v
然后删除远程库信息,关联到gitee
$ git remote rm origin # 删除远程库
$ git remote add origin git@gitee.com:用户名/项目名.git # 关联码云库
$ git remote -v # 再次查看远程库信息
[3]. 同时关联github和码云
使用多个远程库时,我们要注意,git给远程库起的默认名称是origin,如果有多个远程库,我们需要用不同的名称来标识不同的远程库。1). 先删除已关联的名为origin的远程库
$ git remote rm origin
2). 添加Github链接
$ git remote add github git@github.com:用户名/仓库名.git
# 注意远程库叫github不叫origin了
3). 添加码云链接
git remote add gitee git@gitee.com:用户名/仓库名.git
# 注意远程库叫gitee不叫origin了
$ git remote -v # 此时发现关联了github和gitee等多个远程库
[4]. 然后就可以正常的pull和push了
## 更新代码为最新
git pull gitee master
git pull github master
## 推送到github远程库
$ git push github master
## 推送到gitee远程库
$ git push gitee master
## 如果不行就用
git push -u gitee master
忽略特殊文件(不能提交到远程库)
有些文件必须在项目目录,但是又不能提交他们,比如数据库密码配置文件
解决方法:在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件,详情参考廖雪峰git。
忽略文件的原则是:
- 忽略操作系统自动生成的文件,比如缩略图等;
- 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
- 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
有些时候,你想添加一个文件到Git,但发现添加不了,原因是这个文件被.gitignore忽略了
这个时候可以采用两种方法
1). 一种是-f直接强制提交
$ git add -f App.class
2). 一种是检查是不是过滤用的配置文件写错了
$ git check-ignore -v App.class
配置别名(给git命令添加别名)
配制方法:
$ git config --global alias.st status # 执行之后,就可以用st代替status
$ git config --global alias.unstage 'reset HEAD' # 用unstage代替reset HEAD
配置文件:配置好的规则实际上保存在本地的文件里面
配置Git的时候,加上--global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。每个仓库的Git配置文件都放在.git/config文件中,[alias]下面就是别名,可直接添加、修改或删除
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = git@github.com:michaelliao/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[alias]
last = log -1
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。