github笔记
学习网站:廖雪峰https://www.liaoxuefeng.com/wiki/896043488029600
本笔记写了个人的总结、一些命令和操作流程,可帮助快速上手github。
文章目录
一、 电脑上安装git
1、github在不同系统下的安装
(1)、 在Linux上安装Git
(2)、 在Mac OS X上安装Git
(3)、 Windows安装
去官网下载安装包:https://git-scm.com/downloads
2、安装完成后
在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!
安装完成后,还需要最后一步设置,在命令行输入:
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
二、 建立本地库(版本库repository)
创建一个版本库非常简单
1、首先,选择一个合适的地方,创建一个空目录:
$ mkdir learngit
$ cd learngit
$ pwd
pwd命令用于显示当前目录
2、第二步,通过git init命令把这个目录变成Git可以管理的仓库:
$ git init
3、把文件添加到版本库
例如readme.txt文件
(1)第一步,用命令git add告诉Git,把文件添加到仓库:
$ git add readme.txt
(2)第二步,用命令git commit告诉Git,把文件提交到仓库:
$ git commit -m "wrote a readme file"
为什么Git添加文件需要add,commit一共两步呢?因为commit可以一次提交很多文件,所以你可以多次add不同的文件。
三、 注册github账号
请自行注册GitHub账号,百度搜索github,打开官网即可注册
由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:
四、 github上有远程库,本地库和远程库的关联
1、github建立新的远程库
2、将本地库与远程库关联
将这个远程库克隆到本地,本地会生成一个本地库,这个本地库已经和远程库关联
(1)首先,点开repositories,找到需要添加到本地的库,点进去
(2)按如图操作找到SSH,复制圈中的链接
现在,我们根据GitHub的提示,在本地的learngit仓库下运行命令:
git remote add origin git@github.com:michaelliao/learngit.git
(origin后面的部分是刚刚复制的链接)
添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。
3、把文件上传到本地库和远程库
把需要上传的文件复制到本地库的文件夹,添加到本地库,然后上传到github远程库
(1) 首先把需要上传的文件复制到本地库的文件夹
(2) 然后使用git add 指令添加到本地库,也可直接通过git add -A添加所有已修改的文件
git add readme.txt
(3) 使用git commit -m “****”来添加注释并提交到仓库,引号内填写注释
git commit -m “test”
(4) 最后使用git push指令将本地库所有内容推送到远程库
(5) 从现在起,只要本地作了提交,就可以通过命令:
$ git push
把本地master分支的最新修改推送至GitHub,现在,你就拥有了真正的分布式版本库!
4、使用git clone命令从远程库克隆
git clone git@github.com:michaelliao/learngit.git
(clone后面的部分是刚刚复制的链接,同上面添加库时的操作)
(ps:这个远程库可以不是自己已经添加的库,只要有上面那个链接都可以克隆到本地)
五、 版本回溯/前进功能
1、git log可以看历史记录
git reset --hard HEAD^//退回上一版本
git reset --hard HEAD~100//退回上100个版本
2、如果想再改回到未来的某个版本,需要知道它的前几位字符,如图
commit后面的黄色字体即为所需字符,执行以下命令
$ git reset --hard c6584(只需要输前几位就行了,系统会自动回去找的)
3、如果不知道前面文件怎么办
$ git reflog//可以看每一次命令,这样可以看到修改前的文件了
4、撤销上一次修改
$ git checkout -- readme.txt
5、删除文件
$ rm read.text
六、分支与合并
1、创建与合并分支:
创建+切换分支:git checkout -b <name>
或者git switch -c <name>
创建分支:git branch <name>
查看分支:git branch
切换分支git checkout <name>
或者git switch <name>
合并某分支(即:name)到当前分支:git merge <name>
(这是快速合并,之后要学其他的)
删除分支:git branch -d <name>
(备注:
在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支。HEAD
严格来说不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是当前分支。
一开始的时候,master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长。
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
你看,Git创建一个分支很快,因为除了增加一个dev
指针,改改HEAD
的指向,工作区的文件都没有任何变化!
不过,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并:
所以Git合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
)
2、解决冲突:
当master分支与创建的指针分支都做了修改,并且使用快速合并提交时
需要手动修改文件,再提交
3、分支策略:
通常,合并分支时,如果可能,Git会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff
方式的git merge
:
首先,仍然创建并切换dev
分支:
$ git switch -c dev
Switched to a new branch 'dev'
修改readme.txt文件,并提交一个新的commit:
$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+)
现在,我们切换回master
:
$ git switch master
Switched to branch 'master'
准备合并dev
分支,请注意--no-ff
参数,表示禁用Fast forward
:
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit,所以加上-m
参数,把commit描述写进去。
合并后,我们用git log
看看分支历史:
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
* |\
* | * f52c633 (dev) add merge
* |/
* * cf810e4 conflict fixed...
可以看到,不使用Fast forward
模式,merge后就像这样:
4、Bug分支:
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101
来修复它,但是,等等,当前正在dev
上进行的工作还没有提交:
$ git status
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
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
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
现在,用git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在master
分支上修复,就从master
创建临时分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'
现在修复bug,需要把“Git is free software …”改为“Git is a free software …”,然后提交:
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到master
分支,并完成合并,最后删除issue-101
分支:
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到dev
分支干活了!
$ git switch dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
工作区是干净的,刚才的工作现场存到哪去了?用git stash list
命令看看:
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;
另一种方式是用git stash pop
,恢复的同时把stash内容也删了:
$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
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
Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list
查看,就看不到任何stash内容了:
$ git stash list
你可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash,用命令:
$ git stash apply stash@{0}
在master分支上修复了bug后,我们要想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug?重复操作一次,提交不就行了?
有木有更简单的方法?
有!
同样的bug,要在dev上修复,我们只需要把4c805e2 fix bug 101
这个提交所做的修改“复制”到dev分支。注意:我们只想复制4c805e2 fix bug 101
这个提交所做的修改,并不是把整个master分支merge过来。
为了方便操作,Git专门提供了一个cherry-pick
命令,让我们能复制一个特定的提交到当前分支:
$ git branch
* dev
master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交,注意这次提交的commit是1d4b803
,它并不同于master的4c805e2
,因为这两个commit只是改动相同,但确实是两个不同的commit。用git cherry-pick
,我们就不需要在dev分支上手动再把修bug的过程重复一遍。
有些聪明的童鞋会想了,既然可以在master分支上修复bug后,在dev分支上可以“重放”这个修复过程,那么直接在dev分支上修复bug,然后在master分支上“重放”行不行?当然可以,不过你仍然需要git stash
命令保存现场,才能从dev分支切换到master分支。
小结:
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场;
在master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick <commit>
命令,把bug提交的修改“复制”到当前分支,避免重复劳动
5、强行删除:
在没合并前强行删除一个分支:git branch -D <name>
6、多人协作:
查看远程库信息:git remote
或git remote -v
;
推送分支:(在master中推送)
$ git push origin master//推送本地分支
若要推送其他分支如:dev
$ git push origin dev
抓取分支:a.先克隆对方的远程库(用git branch
默认只会看到本地的master分支)
b.要在dev分支上开发(master同理),就必须创建远程origin的dev分支到本地:
$ git checkout -b dev origin/dev
c.现在就可以做修改了:
$ git add 文件名
$ git commit -m "备注"
$ git push origin dev(把dev分支推送到远程)
解决冲突:(对方与我的提交有冲突)
a.先用git pull
把最新的提交从origin/dev
抓下来,然后,在本地合并,解决冲突,再推送:$ git pull
b.如果pull也失败(no tracking information
),那么原因是没有指定本地dev
分支与远程origin/dev
分支的链接,根据提示,设置dev
和origin/dev
的链接:$ git branch --set-upstream-to=origin/dev dev
c.再pull:成功,但是合并有冲突,同“c.2”需要手动解决
d.再推送$ git push origin dev