快速入门Git总结

》》点赞，收藏+关注，理财&技术不迷路《《

mkdir 创建仓库repository

pwd   看位置

git init

（文件夹下会多一个.git文件，若没有，就用ls-ah命令查看）

------------------------------------------------------------------

写一个readme.txt文件

Git is a version control system

Git is free software

一定放在learngit目录下

git add 文件名     将文件加入仓库（可以加多个）

git commit -m “说明”   将文件提交到仓库

git status   查看结果和状态时刻掌握仓库当前的状态

git diff  文件名    看看具体修改了什么内容

git add 文件名    修改完后继续提交

git status   查状态

git commit   提交到仓库----阶段性保存工作

git log  查看所有历史修改记录和作者，显示从最近到最远的提交日志

git log --pretty=oneline    同上，简化输出

--------------------------------------------------------------------

回到上一个版本      版本退回

HEAD表示当前版本，HEAD^上一版本

HEAD^^上上一版本

往上100个版本    HEAD~100

git reset --hard HEAD^     退回上一版本(Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：)

git reflog     用来记录每一次命令  （这个可以查询到说明的commited ，方便退回）

暂存区和版本库

工作区（就是我们自己创建的一个文件夹，比如：learngit） 中有一个隐藏目录.git（目录！！），这不是一个工作区，而是Git的版本库。！！！

git add ———— 提交到了stage（index）

git commit ———— （往master上）提交更改，就是将所有stage区域的文件提交到当前分支（交到Git自动创建的一个分支叫做master（HEAD指向这个分支））

实践（创立一个新的lisence文本文档，并修改我们之前的readme，再查看状态git status发现readme是被修改了，lisence是未追踪状态，但两者都是未提交状态。相当于都在工作区。我们git add，再git status看状态，都是待确认状态，它会告诉你两个文件是新文件还是修改文件之类的。最后git commit -m “说明” 清空暂存区全部提交，再看状态，发现是空的。）

 

管理修改

Git管理的是修改！！不是文件！！

比如先修改一个readme，再git add放入暂存区，再继续修改一次readme，直接git commit，会发现只提交了一个readme到master里面。

用git diff HEAD –- readme.txt来查看工作区和版本库里面最新版的区别。

撤销修改

修改了一个readme.txt（只是放到了工作区还未add到stage）

查看状态git status，是已修改状态

若我们不想要，可以git checkout – file来丢弃工作区这个文件;这个时候readme.txt会回到上一版本的状态！！

git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

修改了一个readme还放到了stage：在add后，在commit之前。

git status发现只是暂存了还没有提交。

现在想要撤销这个暂存区的，分两步：1.从暂存区撤离到工作区（git reset HEAD –- file）。 2.再git checkout –- file 丢弃工作区的。

 

删除文件

创一个新的test文件，然后git add提交到暂存区；然后删掉test文件（rm test），再继续git status会发现它仍然还在暂存区，并且还有之前的操作记录。

rm是从工作区中删除该文件

git rm是可以从暂存区里面删除

如果没有git commit -m 存到版本库的话是无法恢复最新版本的。但是若存到了版本库，误删了工作区或者暂存区的，是可以恢复的。

若工作区删了，暂存区也删了，版本库有： 

1.可以用git checkout HEAD 文件名 来恢复到工作区（！！！！这种方法是危险的，他不会管你的工作区test是否保存，运行这个命令后，它会全部用版本库的test来覆盖你工作区的test）

2.可以  版本库——暂存区——工作区     版本库到暂存区：git reset HEAD test    暂存区到工作区： git checkout – test （！！这也是危险的，道理同上）

远程仓库（Git的优势之一）

可以自己搭建一个远程仓库，但是非常麻烦，可以选择注册一个hithub帐号，hithub可以作为一个免费的Git远程仓库。

本地Git仓库和Hithub仓库之间的传输是通过SSH加密的！

看看home下有没有id_rsa（私钥，不能告诉别人）和id_rsa.pub（公钥，可以告诉别人）这两个文件（这两个文件都在.ssh下面）。如果home下面没有的话，就$ ssh-keygen -t rsa -C "youremail@example.com"  创建。

再在设置里面SSHkey里面放上你复制粘贴的密钥。（赋值.ssh下面的id_rsa.pub,然后粘贴）

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

添加远程仓库

我们本地有了一个learngit的仓库

我们也可以在github上面再建一个仓库来备份。

可以把本地已有的仓库和github上的克隆仓库连接：

1.进入到本地仓库里面

2.输入：$ git remote add origin git@github.com:michaelliao/learngit.git（这里可以改成自己对应的git@github.com:XIANG-1996/learngit.git，创建一个new repository后，可以在SSH看到）远程仓库名字就叫做：origin！！

再把自己的内容推上github：$ git push -u origin master     （git push是命令，实际相当于把master分支推送到远程。因为远程是空的，所以加上了参数 -u，所以不仅会将内容推送上去，还会将本地分支master和远程的master分支关联起来。）

以后再提交东西就可以直接 git push origin master

要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！

 

从远程库克隆

上面是1. 先有本地仓库 2. 然后再有远程仓库 3. 再关联二者

现在我们从零出发，先建立远程仓库，然后从远程仓库克隆下来

先创立一个新的repository， 可以选择我们勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件。

现在远程仓库准备好了，下一步可以开始用命令git clone 克隆出来一个本地库。

git clone git@github.com:XIANG-1996/gitskills.git

分支管理

Git又一优势：分支管理（SVN等等其他的也有分支管理，但是创建和切换特别特别慢）Git不管是创建，切换，删除（即使有一万个文件），都可以一秒完成。

主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

新建立分支并且合并分支：建立dev分支，然后再切换到dev分支。

git checkout -b dev 或者 git switch -c dev    命令加上-b参数表示创建并切换，相当于以下两条命令：

git branch dev(创建这个分支) 

git checkout dev（切换到这个分支上来）

git branch 是列出所有分支。  当前分支前面会有*

git checkout master   切换回之前的master分支 （也可以用git switch ***，因为前面git checkout –-file 是用来撤销修改的，容易混淆）

我们在dev分支里面将readme.txt修改后，再回到master分支，看不到之前dev分支的修改。

现在把dev分支上的工作合并到master上。

Git merge dev

现在在master里面也可以看到dev里面修改的东西了。

现在合并后就可以安心的删除dev了！！

删除dev：git branch -d dev

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>或者git switch <name>

创建+切换分支：git checkout -b <name>或者git switch -c <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

解决冲突

创建一个新的branch，在这个新的branch里面修改readme然后add和commit

再回到master里面对readme修改，然后add和commit。

尝试合并，git merge feature1

即使我们查询status发现他告诉我们的也是冲突。

因此需要先手动解决这个冲突，而且会发现在这个冲突下我们叶不能更改我们的branch。

我们在这个下面直接修改readme.txt,就有了如下转化：相当于在master又改了一次。

第一次feature1改了，然后退出进入master改一次。这个时候就是左边那个图，想试图合并里那个个readme发现不行，出错，这个时候进入readme（两者有关联了）修改后在master基础上修改readme就相当与feature1和master联系起来了。

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log –graph命令可以看到分支合并图。

分支管理策略

分支合并的时候，采用的是Fast forward模式。

如果我们想强制禁用Fast forward模式Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。下面我们实战一下--no-ff方式的git merge：

1.建立并且换dev

2. dev下面修改readme，然后add和commit把它提交

3.然后我们回到master来合并dev，git merge --no-ff -m "merge with no-ff" dev，--no-ff参数，表示禁用Fast forward：

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

 

 

Bug分支

每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

git status 会发现dev上还有东西未提交。

重点！！！！   你从master这个branch上面$ git checkout -b issue-101那么这个新的issue-101分支是属于master的，你要是再切换到dev再建立分支，那么这个分支就属于dev。     

 

Feature分支

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

接到一个新的任务，开发某新功能vulcan

$ git switch -c feature-vulcan

然后add vulcan.py     git commit -m “”

我们切换回dev，然后准备合并再删除feature

在这个时候，这个新功能必须取消！而且为了保密，这个feature分支都必须销毁

$ git branch -D feature-vulcan

这个命令是强行删除。

 

多人协作

从远程仓库克隆时，实际就是Git自动把本地的master分支和远程的master分支对应起来，并且远程仓库的默认名为origin。

查看远程库的信息：git remote

查看远程库更详细信息：git remote -v

上面显示了可以抓取和推送的origin的地址。如果没有push权限，就不会显示这条。

------推送分支（git push origin ***）

git push origin master

git push origin dev（推送其他的分支）

并不是一定要将所有本地分支往远程推送！！

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

----------抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

在另一台电脑（要把SSH Key添加到GitHub）或者同一电脑的另一个目录下克隆。

$ git clone git@github.com:michaelliao/learngit.git

当从别的设备克隆时，只能看到本地master分支。

如果要在dev分支上开发，就必须创建远程origin的dev分支到本地。

$ git checkout -b dev origin/dev

多人协作不是很懂！！！！日后看

Rebase（与多人协作有关，日后看）

 

标签管理

标签是版本库的一个快照，Git的标签虽然是版本库的快照，但其实他就是一个指向某个commit的指针（分支可以移动，标签不能移动），所以创建和删除都是瞬间完成的

Git有commit为什么还要tag呢？

commit的号：6a58192…    这个太复杂不好找

换一个办法：

把某一次的版本打包发布，版本号是v1.2,然后按照tag v1.2查找commit就行，tag就是和commit绑在一起的！

创建标签

git branch到你想打标签的分支

git tag v1.0  打上标签名

标签默认打在最新提交的commit上

如果某次忘记打上标签，几天后回去打，可以：

1.$git log --pretty=oneline --abbrev-commit     查找历史提交的commit ID

2.git tag v1.1 ID

3. git show tagname （git show v0.9）

4. 还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

命令git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；

命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；

命令git tag可以查看所有标签。

操作标签

删除标签：git tag -d v0.1（仅限本地删除，要是想删除远程，见后面）

推送某个标签到远程：git push origin V1.0

一次性推送全部本地标签：git push origin -tags

删除远程标签：1. 先删除本地标签，git tag -d v0.9  2. 从远程删除： git push origin：refs/tags/v0.9   3. 登录github查看是否删除

 

小结

命令git push origin <tagname>可以推送一个本地标签；

命令git push origin --tags可以推送全部未推送过的本地标签；

命令git tag -d <tagname>可以删除一个本地标签；

命令git push origin :refs/tags/<tagname>可以删除一个远程标签。