学习廖雪峰的Git教程所记的笔记,Git教程 - 廖雪峰的官方网站https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
Windows下Git教程
1. Git简介
1.1. Git的诞生
Linus创建了Linux,世界各地人把源代码diff给Linus,2002年前Linus手工合并代码。
2002年后,商业版本控制系统BitKeeper的东家BitMover公司,授权Linux社区免费使用。
2005年,开发Samba的Andrew试图破解BitKeeper的协议,被BitMover公司发现,要收回免费使用权。
Linus本可以道歉,然后管教弟兄们,嗯,这是不可能的。实际情况是:
Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git!一个月之内,Linx系统的源码已经由Git管理了!
牛是怎么定义的呢?大家可以体会一下。
2008年,GitHub网站上线。
1.2. 集中式vs分布式
集中式,版本库是集中存放在中央服务器的,用自己电脑从中央服务器取得最新版本再干活。
干完活,再把自己的活推送给中央服务器。中央服务器好比图书馆,改书,先借,回家改,改完,再放回。
集中式必须联网才能工作。
集中式版本控制,中央服务器出问题了,所有人都没发干活了。
分布式,每个人的电脑上都是一个完整的版本库。
分布式版本控制系统安全性高。每个人电脑都有完整的版本库,一个人的没了,从其他人那复制。
分布式版本控制通常也有一台充当“中央服务器”的电脑,方便交换大家的修改。
还有强大的分支管理功能。
2.安装Git
在Windows上安装Git,在Windows上使用Git,可以从Git官网直接下载安装程序,然后按默认选项安装即可。
安装完成后,在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!
2.1.增加用户名和Email
安装好git后,分布式版本控制,机器自报家门,增加用户名和密码
git config --global user.name username
git config --global user.email xxxxxx@xx.com
查看仓库当前状态
git status
2.2.建文件夹。
mkdir learngit
cd learngit
pwd
2.3.把目录编程Git可以管理的仓库:
git init
查看目录下所有隐藏文件
ls -ah
3.创建版本库
3.1.把文件添加到仓库,可添加多个文件
git add readme.txt file1.txt file2.txt
3.2.把文件提交到仓库
git commit -m "wrote a readme file,add 3 files"
4.时光机穿梭
git add
git commit -m ""
git diff
git status
4.1.版本回退
git log 显示提交日志
git log --pretty=oneline 嫌输出信息太多,可以加上 --pretty=oneline参数
git reset --hard HEAD^
HEAD当前版本;
HEAD^上个版本;
HEAD^^上上个版本;
往上100个版本HEAD~100
cat readme.txt ;git bash里查看文件内容
git reflog ;查看历史命令
git reset --hard commit_id;
4.2.工作区和暂存区
工作区(Working Directory):电脑里能看到的目录,如learngit就是一个工作区。
版本库(Respository):工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。
版本库里最重要的称为stage(或者叫index)的暂存区,
还有git自动创建的第一个分支master,以及指向master的指针HEAD。
4.3.管理修改
Git比其他版本控制系统设计的优秀,是因为Git跟踪并管理的是修改,而非文件。如:
1
一改:12 后git add,git status 不同
二改:123后git commit,git status 相同
第一次修改 -> git add -> 第二次修改 -> git commit
第一次修改,git add后,工作区的第一次修改 放入 暂存区,准备提交。
第二次修改 没放入 暂存区, git commit 只负责把暂存区的修改提交。
也就是 第一次修改被提交,第二次修改不会被提交。
git status 查看的是暂存区是否更改
git diff HEAD -- readme.txt可以查看版本库和工作区里最新版本的区别。
提交第二次修改,需要再次 git add
4.4.撤销更改
git checkout -- readme.txt ;丢弃工作区的修改,工作区是干净的(clean)。让工作区和暂存区里的版本一致,暂存区版本为最近一次git add的状态
git checkout -- filename ;--很重要,没有--就变成了切换到另一个分支的命令 git checkout branch_name。
git reset HEAD readme.txt ;把暂存区修改撤销掉(unstage),暂存区是干净的(clean)
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD file,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
4.5.删除文件
删除工作区文件后,要
git rm filename
git commit -m
5.远程仓库
自行注册GitHub帐号,本地Git仓库和GitHub仓库直接的传输是通过SSH加密的。
第一步:
创建SSH Key。用户主目录下,看看有没有.ssh目录。
有的话,看目录下有没有id_rsa和id_rsa.pub,有的话,直接跳到第二步,
没有的话打开Git Bash,创建SSH Key:
ssh-keygen -t rsa -C "xxxx@xx.com"
把邮件地址换成自己的地址,一直回车,使用默认值。
完成后,目录下有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的密钥对。
id_rsa是私钥id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以告诉任何人。
第二步:
登录GitHub,打开“Settings”,“SSH and GPG keys”页面。
点击New SSH key,填上任意Title,
在Key文本框里粘贴id_rsa.pub文件的内容,
点击下方 Add SSH key。
输入密码,确认。
为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。
当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。
5.1.添加远程库
登陆GitHub,找到“Create a new repo”按钮
在Repository name填入learngit,其他保持默认设置,
点击下方“Create repository”按钮,就成功地创建了一个新的Git仓库:
现在,我们根据GitHub的提示,在本地的learngit仓库下运行命令:
git remote add origin git@github.com:ycanye2009/learngit.git
请千万注意,把上面的ycanye2009替换成你自己的GitHub账户名,
否则,你在本地关联的就是我的远程库,关联没有问题,
但是你以后推送是推不上去的,因为你的SSH Key公钥不在我的账户列表中。
添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,
但是origin这个名字一看就知道是远程库。
下一步,就可以把本地库的所有内容推送到远程库上:
git push -u origin master
把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。
由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,
还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
只要本地作了提交,就可以通过命令:
git push origin master
把本地master分支的最新修改推送至Github。
SSH警告
当你第一次使用Git的clone或者push命令连接GitHub时,会得到一个警告。
这是因为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 remote add origin git@server-name:path/repo-name.git;
关联后,使用命令git push -u origin master第一次推送master分支的所有内容;
此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;
5.2.从远程库克隆
git clone git@github.com:ycanye2009/learngit.git
要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。
Git支持多种协议,包括https,但通过ssh支持的原生git协议速度最快。
6.分支管理
6.1.创建与合并分支。
I.每次提交,都串成一条时间线,这条时间线就是一个分支。在Git里这个分支叫主分支,即master分支。
HEAD不指向提交,而是指向master,master指向提交。
II.创建新分支,例如dev,建立一个dev指针,指向master相同的提交,把HEAD指向dev,表示当前分支在dev上。
III.对工作区的修改和提交,就是针对dev分支了。
IV.dev完成,dev合并到master,master指向当前提交,HEAD指向master。
V.合并完成,删除dev分支。
小结
Git鼓励大量使用分支:
查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支到当前分支:git merge <name>
Fast-forward “快进模式”
删除分支:git branch -d <name>
6.2.解决冲突。
当Git无法自动合并分支时,就必须首先解决冲突。
解决冲突后,再提交,合并完成。
用git log --graph命令可以看到分支合并图
6.3.分支管理策略
I.master分支非常稳定,仅用来发布新版本,平时不能在上面干活。
II.dev分支,不稳定,发布时,把dev分支合并到master上,在master上发布。
小结
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上--no-ff参数就可以用普通模式合并,
合并后的历史有分支,能看出来曾经做过合并,
而fast forward合并就看不出来曾经做过合并。
6.4.Bug分支
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交:
暂存区是公用的,如果不通过stash命令隐藏,会带到其它分支(issue-101)去
幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:git stash
Git的stash恢复,有两个办法:
一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;
另一种方式是用git stash pop,恢复的同时把stash内容也删了:
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,用git stash list查看,再git stash pop,回到工作现场。
6.5.Feature分支
开发一个新功能(feature),最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>强行删除。
6.6.多人协作
I.查看远程库 git remote ;查看远程库详细信息用 git remote -v,无推送权限,则看不到push地址
II.推送分支 切换到master分支,git push origin master;切换到dev分支,git push origin dev
需要推送的分支:
master分支是主分支,因此要时刻与远程同步;
dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!
III.抓取分支
克隆只会克隆master分支,你的小伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,
于是他用这个命令创建本地dev分支: git checkout -b dev origin/dev ;创建与远程仓库同步的分支。
多人协作的工作模式通常是这样:
首先,可以试图用git push origin branch-name推送自己的修改;
如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
如果合并有冲突,则解决冲突,并在本地提交;
没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功!
如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式,一旦熟悉了,就非常简单。
小结
查看远程库信息,使用git remote -v;
本地新建的分支如果不推送到远程,对其他人就是不可见的;
从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;
在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;
建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;
从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。
7.标签管理
发布一个版本时,我们通常先在版本库中打一个标签(tag)。
标签是版本库的快照,是指向某个commit的指针,跟分支很像,但分支可以移动,标签不能移动
创建和删除标签都是瞬间完成的。
tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起
7.1创建标签
打一个新标签,默认标签是打在最新提交的commit上的:git tag v1.0
给某次提交打标签:git tag v10.9 <commit_id>
查看所有标签:git tag ;标签不是按时间顺序列出,而是按字母排序的。
查看标签信息:git show <tagname>
创建带有说明的标签,用-a指定标签名,-m指定说明文字:git tag -a v0.1 -m "version 0.1 released" 3628164
可以通过-s用私钥签名一个标签:
通过-s用私钥签名一个标签:git tag -s v0.2 -m "signed version 0.2 released" fec145a
小结
命令git tag <name>用于新建一个标签,默认为HEAD,也可以指定一个commit id;
git tag -a <tagname> -m "blablabla..."可以指定标签信息;
git tag -s <tagname> -m "blablabla..."可以用PGP签名标签;
命令git tag可以查看所有标签。
7.2.操作标签
删除标签:git tag -d v0.1
推送某个标签到远程,使用命令git push origin <tagname>:
一次性推送全部尚未推送到远程的本地标签:git push origin --tags
如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:
git tag -d v0.9
然后,从远程删除。删除命令也是push,但是格式如下:
git push origin :refs/tags/v0.9
小结
命令git push origin <tagname>可以推送一个本地标签;
命令git push origin --tags可以推送全部未推送过的本地标签;
命令git tag -d <tagname>可以删除一个本地标签;
命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
8.使用GitHub
fork
clone
push
pull request
小结
在GitHub上,可以任意Fork开源仓库;
自己拥有Fork后的仓库的读写权限;
可以推送pull request给官方仓库来贡献代码。
用git remote -v查看远程库信息
9.自义Git
让Git显示颜色,会让命令输出看起来更醒目:git config --global color.ui true
9.1.忽略特殊文件
.gitignore
忽略文件的原则是:
I.忽略操作系统自动生成的文件,比如缩略图等;
II.忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
III.忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
一个完整的.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。
小结
忽略某些文件时,需要编写.gitignore;
.gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!
9.2.配置别名
I.git status别名git st:git config --global alias.st status
当然还有别的命令可以简写,很多人都用co表示checkout,ci表示commit,br表示branch:
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
II.git reset HEAD file可以把暂存区的修改撤销掉(unstage),重新放回工作区。
既然是一个unstage操作,就可以配置一个unstage别名:
$ git config --global alias.unstage 'reset HEAD'
III.配置一个git last,让其显示最后一次提交信息:
$ git config --global alias.last 'log -1'
甚至还有人丧心病狂地把lg配置成了:
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
IV.配置Git的时候,加上--global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。
V.配置文件放哪了?每个仓库的Git配置文件都放在.git/config文件中:
$ cat .git/config
[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
别名就在[alias]后面,要删除别名,直接把对应的行删掉即可。
VI.而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中:
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中:
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = your@email.com
配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置。
小结
给Git配置好别名,就可以输入命令时偷个懒。我们鼓励偷懒。
END. 附录:GIT备忘单(GIT CHEAT SHEET)
1.CREATE
Clone an existing repository
$ git clone ssh://user@domain.com/repo.git
Create a new local repository
$ git init
2.LOCAL CHANGES
Changed files in your working directory
$ git status
Changes to tracked files
$ git diff
Add all current changes to the next commit
$ git add .
Add some changes in <file> to the next commit
$ git add -p <file>
Commit all local changes in tracked files
$ git commit -a
Commit previously staged changes
$ git commit
Change the last commit
Don‘t amend published commits!
$ git commit --amend
3.COMMIT HISTORY
Show all commits, starting with newest
$ git log
Show changes over time for a specific file
$ git log -p <file>
Who changed what and when in <file>
$ git blame <file>
4.BRANCHES & TAGS
List all existing branches
$ git branch -av
Switch HEAD branch
$ git checkout <branch>
Create a new branch based
on your current HEAD
$ git branch <new-branch>
Create a new tracking branch based on
a remote branch
$ git checkout --track <remote/branch>
Delete a local branch
$ git branch -d <branch>
Mark the current commit with a tag
$ git tag <tag-name>
5.UPDATE & PUBLISH
List all currently configured remotes
$ git remote -v
Show information about a remote
$ git remote show <remote>
Add new remote repository, named <remote>
$ git remote add <shortname> <url>
Download all changes from <remote>,
but don‘t integrate into HEAD
$ git fetch <remote>
Download changes and directly
merge/integrate into HEAD
$ git pull <remote> <branch>
Publish local changes on a remote
$ git push <remote> <branch>
Delete a branch on the remote
$ git branch -dr <remote/branch>
Publish your tags
$ git push --tags
6.MERGE & REBASE
Merge <branch> into your current HEAD
$ git merge <branch>
Rebase your current HEAD onto <branch>
Don‘t rebase published commits!
$ git rebase <branch>
Abort a rebase
$ git rebase --abort
Continue a rebase after resolving conflicts
$ git rebase --continue
Use your configured merge tool to
solve conflicts
$ git mergetool
Use your editor to manually solve conflicts
and (after resolving) mark file as resolved
$ git add <resolved-file>
$ git rm <resolved-file>
7.UNDO
Discard all local changes in your working
directory
$ git reset --hard HEAD
Discard local changes in a specific file
$ git checkout HEAD <file>
Revert a commit (by producing a new commit
with contrary changes)
$ git revert <commit>
Reset your HEAD pointer to a previous commit
…and discard all changes since then
$ git reset --hard <commit>
…and preserve all changes as unstaged
changes
$ git reset <commit>
…and preserve uncommitted local changes
$ git reset --keep <commit>