学习了一上午大神廖雪峰写的git教程,特此记录以下
参考:https://www.liaoxuefeng.com/wiki/896043488029600
git config 查看配置信息
- config 配置命令:git config
- config 配置有system级别 global(用户级别) 和local(当前仓库)三个 设置先从system-》global-》local 底层配置会覆盖顶层配置 分别使用--system/global/local 可以定位到配置文件
- 查看系统config:
git config --system --list
- 查看当前用户(global)配置
git config --global --list
- 查看当前仓库配置信息
git config --local --list
or
git config --local -l
初始化本地仓库
mkdir learngit
cd learngit
git init
git修改提交文件
提交修改文件到暂存区:git add readme.txt readme1.txt
提交修改到本地仓库:git commit -m "your modification description"
查看状态:git status
查看修改日志: git log
日志显示一行:git log --pretty=oneline
修改文件后,提交到暂存区之前查看修改内容:git diff readme.txt
如果git status告诉你有文件被修改过,用git diff可以查看修改内容
版本回退
回退到上一个版本:
$ git reset --hard HEAD^
HEAD is now at ef46b9f test diff
回退到下一个版本:
用git log命令找到id,
$ git reset --hard id
查看所有操作命令:
git reflog
利用此命令可以查看提交记录的id.
HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id。
穿梭前,用git log可以查看提交历史,以便确定要回退到哪个版本。
要重返未来,用git reflog查看命令历史,以便确定要回到未来的哪个版本。
工作区和暂存区
- 工作区(Working Directory)
就是你在电脑里能看到的目录,比如我的learngit文件夹就是一个工作区 - 版本库(Repository)
工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。
你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
管理修改
查看工作区和版本库(暂存区)里面最新版本的区别:
git diff HEAD -- readme.txt
git commit只负责把暂存区的修改提交.
每次修改,如果不用git add到暂存区,那就不会加入到commit中.
撤销修改
- 如果修改了文件,还没有git add到暂存区
git checkout -- file可以丢弃工作区的修改
在修改文件后,git add之前可以用以下命令丢弃工作区的修改:
git checkout -- readme.txt
- 如果修改文件后,git add提交到了暂存区:
用命令git reset HEAD 可以把暂存区的修改撤销掉(unstage),重新放回工作区
用命令git checkout命令把工作区的修改撤销掉。
git reset HEAD readme.txt
git checkout -- readme.txt
git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区
- 如果文件修改后,git add提交了暂存区,并且git commit到版本库,可以用git reset --hard HEAD^回到上一版本
git reset --hard HEAD^
删除文件
新增一个文件,git add,git commit.然后删除新增文件。
git add test.txt
git commit -m "add test.txt"
rm test.txt
git status
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit
git rm test.txt
git commit -m "remove test.txt"
第二种情况:删错了文件,需要把误删的文件找回来:
git checkout -- test.txt
远程仓库
生成ssh key
ssh-keygen -t rsa -C "youremail@example.com"
在github中找到设置,添加ssh key,把本地目录中生成的id_rsa.pub内容复制到github中,保存。
添加远程仓库
- 新建仓库的情况:
echo "# learngit" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/riyuexing/learngit.git
git push -u origin master
- 添加本地现有仓库到远程仓库
git remote add origin https://github.com/riyuexing/learngit.git
git push -u origin master
- 复制其他仓库到新创建的仓库:
You can initialize this repository with code from a Subversion, Mercurial, or TFS project.
输入git 仓库地址:
从远程仓库克隆
要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。
Git支持多种协议,包括https,但通过ssh支持的原生git协议速度最快。
分支管理
创建与合并分支
- 创建并切换到dev分支
git checkout -b dev
上一条命令相当于:
git branch dev
git checkout dev
查看当前分支:
git branch
- 修改readme.txt,然后提交
git add readme.txt
git commit -m "branch test"
- 切换到master分支
git checkout master
- 合并dev分支到master分支
git merge dev
- 删除dev分支
git branch -d dev
Git鼓励大量使用分支:
查看分支:git branch
创建分支:git branch
切换分支:git checkout
创建+切换分支:git checkout -b
合并某分支到当前分支:git merge
删除分支:git branch -d
解决冲突
- 创建新分支
git checkout -b feature1
- 修改readme.txt文件最后一行
Creating a new branch is quick AND simple. - 提交修改
git add readme.txt
git commit -m "AND simple"
- 切换到master分支
git checkout master
在master分支上把readme.txt文件的最后一行改为:
Creating a new branch is quick & simple.
提交修改
git add readme.txt
git commit -m "& simple"
- 现在git merge会出现冲突:
git merge feature1 果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
我们可以直接查看readme.txt的内容:
Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容,我们修改最后一行如下后保存,并提交:
Creating a new branch is quick and simple.
git add readme.txt
git commit -m "conflict fixed"
- 用带参数的git log可以看到分支的合并情况:
git log --graph --pretty=oneline --abbrev-commit
- 删除feature1分支
git branch -d feature1
分支管理策略
通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
- 首先,仍然创建并切换dev分支:
git checkout -b dev
- 修改readme.txt文件,并提交一个新的commit:
在readme.txt中添加一行:
merge branch with "--no--off".
git add readme.txt
git commit -m "add merge"
- 切换到master
git checkout master
- 合并dev分支
git merge --no-ff -m "merge with no-ff" dev
- 查看分支历史
git log --graph --pretty=oneline --abbrev-commit
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
Bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash(藏匿)功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
git stash
现在,用git status查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支:
git checkout master
git checkout -b issue-101
现在修复bug,需要把“Git is free software ...”改为“Git is a free software ...”,然后提交:
git add readme.txt
git commit -m "fix bug 101"
修复完成后,切换到master分支,并完成合并,最后删除issue-101分支:
git checkout master
git merge --no-ff -m "merge bug fix 101" issue-101
现在,是时候接着回到dev分支干活了!
git checkout dev
git status
工作区是干净的,刚才的工作现场存到哪去了?用git stash list命令看看:
git stash list
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;
另一种方式是用git stash pop,恢复的同时把stash内容也删了:
你可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令:
git stash apply stash@{0}
Feature分支
软件开发中,总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
现在,你终于接到了一个新任务:开发代号为Vulcan的新功能,该功能计划用于下一代星际飞船。
于是准备开发:
git checkout -b feature-starship
开发完成,提交
git add starship.txt
git commit "add starship feature"
切换到dev分支:
git checkout master
此时删除feature-starship分支,会失败:
git branch -d feature-starship
可以强行删除:
git branch -D feature-starship
开发一个新feature,最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D 强行删除。
多人协作
查看远程仓库的信息:
git remote
查看更加详细的信息:
git remote -v
上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
git push origin master
如果要推送其他分支,比如dev,就改成:
git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
master分支是主分支,因此要时刻与远程同步;
dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!
抓取分支
git clone git@github.com:michaelliao/learngit.git
当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的master分支。
git branch
如果想切换到远程dev分支
git checkout -b dev origin/dev
推送到远程dev分支:
git push origin dev
如果多人修改,推送到远程时会碰到冲突,推送失败,解决方法:先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送
git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:
git branch --set-upstream-to=origin/dev dev
再pull:
git pull
这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push:
因此,多人协作的工作模式通常是这样:
首先,可以试图用git push origin 推送自己的修改;
如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
如果合并有冲突,则解决冲突,并在本地提交;
没有冲突或者解决掉冲突后,再用git push origin 推送就能成功!
如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to origin/。
Rebase 变基(再学)
rebase操作可以把本地未push的分叉提交历史整理成直线;
rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。
标签管理
发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。
Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
tag比commit更好记,tag不能移动,commit能移动
tag跟摸一个commit绑定在一起
创建标签:
查看标签:git tag
给当前commit打标签: git tag v1.0
给某个commit打标签:
git log --pretty=oneline --abbrev-commit
找出commit id,再打标签
git tag v0.9 b455ad5
查看标签详情
git show v0.9
创建带有说明的标签
git tag -a v0.1 -m "version 0.1 released" b455ad5
标签总是和某个commit挂钩。如果这个commit既出现在master分支,又出现在dev分支,那么在这两个分支上都可以看到这个标签。
操作标签
- 本地删除,此时标签还未推送的远程仓库
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
命令git push origin 可以推送一个本地标签;
命令git push origin --tags可以推送全部未推送过的本地标签;
命令git tag -d 可以删除一个本地标签;
命令git push origin :refs/tags/可以删除一个远程标签。
一个本地库关联多个远程仓库
- 关联一个远程仓库:
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
之后就可以正常git push,git pull
- 删除已有的远程仓库
git remote rm origin
- 关联多个仓库
git remote add github git@github.com:michaelliao/learngit.git
git remote add gitee git@gitee.com:liaoxuefeng/learngit.git
push的时候:
git push github master
git push gitee master
自定义git
让Git显示颜色,会让命令输出看起来更醒目
git config --global color.ui true
忽略特殊文件
有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦,等等,每次git status都会显示Untracked files ...,有强迫症的童鞋心里肯定不爽。
好在Git考虑到了大家的感受,这个问题解决起来也很简单,在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。
忽略文件的原则是:
忽略操作系统自动生成的文件,比如缩略图等;
忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
- 在.gitignore文件中添加忽略的文件
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
# My configurations:
db.ini
deploy_key_rsa
- 把.gitignore也提交到Git,就完成了!当然检验.gitignore的标准是git status命令是不是说working directory clean。
使用Windows系统要注意,如果你在资源管理器里新建一个.gitignore文件,它会提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
有些时候,你想添加一个文件到Git,但发现添加不了,原因是这个文件被.gitignore忽略了
如果你确实想添加该文件,可以用-f强制添加到Git
git add -f App.class
或者你发现,可能是.gitignore写得有问题,需要找出来到底哪个规则写错了,可以用git check-ignore命令检查:
git check-ignore -v App.class