参考网址:https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
Table of Contents
远程仓库
GitHub,从名字就可以看出,这个网站就是提供Git仓库托管服务的,所以,只要注册一个GitHub账号,就可以免费获得Git远程仓库。请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:
- 第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有
id_rsa
和id_rsa.pub
这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:ssh-keygen -t rsa -C "2428398687@qq.com"
你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。
如果一切顺利的话,可以在用户主目录里找到
.ssh
目录,里面有id_rsa
和id_rsa.pub
两个文件,这两个就是SSH Key的秘钥对,id_rsa
是私钥,不能泄露出去,id_rsa.pub
是公钥,可以放心地告诉任何人。 -
登陆GitHub,打开“Account settings”,“SSH Keys”页面:然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴
id_rsa.pub
文件的内容:点“Add Key”,你就应该看到已经添加的Key
添加远程库
- 在github上创建一个repository,取名learngit.
- 将上一节的创建的库push上去
git remote add origin git@github.com:libobo6/learngit.git git push -u origin master
要关联一个远程库,使用命令
git remote add origin git@server-name:path/repo-name.git
;关联后,使用命令
git push -u origin master
第一次推送master分支的所有内容;此后,每次本地提交后,只要有必要,就可以使用命令
git push origin master
推送最新修改;添加后,远程库的名字就是
origin
,这是Git默认的叫法,也可以改成别的,但是origin
这个名字一看就知道是远程库。把本地库的内容推送到远程,用
git push
命令,实际上是把当前分支master
推送到远程。由于远程库是空的,我们第一次推送
master
分支时,加上了-u
参数,Git不但会把本地的master
分支内容推送的远程新的master
分支,还会把本地的master
分支和远程的master
分支关联起来,在以后的推送或者拉取时就可以简化命令。当你第一次使用Git的clone
或者push
命令连接GitHub时,会得到一个警告.这是因为Git使用SSH连接,而SSH连接在第一次验证GitHub服务器的Key时,需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器,输入
yes
回车即可。Git会输出一个警告,告诉你已经把GitHub的Key添加到本机的一个信任列表里了.
从远程库克隆
要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone
命令克隆。
Git支持多种协议,包括https
,但通过ssh
支持的原生git
协议速度最快。
分支管理
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
创建与合并分支
在Git里,HEAD
严格来说不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是当前分支。
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变,假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并.合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支.详情请见:点击这里 .
创建并切换分支
git checkout -b dev
git checkout
命令加上-b
参数表示创建并切换,相当于以下两条命令:
git branch dev
git checkout dev
查看当前分支: 命令会列出所有分支,当前分支前面会标一个*
号。
git branch
dev
分支的工作成果合并到master
分支上:
git merge dev
合并完成后,就可以放心地删除dev
分支了:
git branch -d dev
查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>
解决冲突
当两个分支都有新的提交时如下图:
这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:
git merge dev
自动合并 readme.txt
冲突(内容):合并冲突于 readme.txt
自动合并失败,修正冲突然后提交修正的结果。
现在发现冲突后我们去指定文件中修改相应的信息,再次add和commit提交文件.
可以用带参数的git log
也可以看到分支的合并情况:
git log --graph --pretty=oneline --abbrev-commit
* 9dcf58c (HEAD -> master) test3 master and dev
|\
| * 36fba30 (dev) test1 dev
* | 886d285 test2 master
|/
* dca5496 branch test
* 5ebf93b (origin/master) add readme.txt
* 2ff850d remove readme
* bd2e69f add learn
* 921b037 wrote a readme file
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。
用git log --graph
命令可以看到分支合并图。
分支管理策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
合并分支时,加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward
合并就看不出来曾经做过合并。
git merge --no-ff -m "merge with no-ff" dev
Bug分支
Git还提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
git stash
保存工作目录和索引状态 WIP on master: 9dcf58c test3 master and dev
用git stash list
命令查看:
git stash list
stash@{0}: WIP on master: 9dcf58c test3 master and dev
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
- 用
git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除; - 另一种方式是用
git stash pop
,恢复的同时把stash内容也删了:
你可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash,用命令:
git stash list
stash@{0}: WIP on master: 9dcf58c test3 master and dev
git stash apply stash@{0}
feature分支
开发一个新feature,最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>
强行删除。
多人协作
多人协作的工作模式通常是这样:
-
首先,可以试图用
git push origin <branch-name>
推送自己的修改; -
如果推送失败,则因为远程分支比你的本地更新,需要先用
git pull
试图合并; -
git pull
也失败了,原因是没有指定本地dev
分支与远程origin/dev
分支的链接,根据提示,设置dev
和origin/dev
的链接:git branch --set-upstream-to=origin/dev dev
然后继续git pull;
-
如果合并有冲突,则解决冲突(如上述小节),并在本地提交;
-
没有冲突或者解决掉冲突后,再用
git push origin <branch-name>
推送就能成功
如果git pull
提示no tracking information
,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to <branch-name> origin/<branch-name>
。
一般情况下分支的类型:
-
master
分支是主分支,因此要时刻与远程同步; -
dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步; -
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
-
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
常用命令:
-
查看远程库信息,使用
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
,如果有冲突,要先处理冲突。
Rebase
-
rebase操作可以把本地未push的分叉提交历史整理成直线;
-
rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。