Git使用
本文共--字 阅读约--分钟 | 浏览: -- Last Updated: 2021-02-26
集中式 VS 分布式
集中式版本控制系统
SVN就是集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，要先从中央服务器取得最新的版本，干完活了再把自己的活推送给中央服务器。
缺点：
1、历史库存在于中央仓库，每次对比与提交代码都必须连接到中央仓库才能进行（需要联网）
2、中央服务器要是出了问题，所有人都没法干活了。
分布式版本控制系统
GIT是分布式版本控制系统，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库（安全，版本库在本地就无需联网了，自己可以在脱机环境查看开发的版本历史 ），多人协作的时候只需把各自的修改推送给对方，就可以互相看到对方的修改了。
分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
多人开发时如果充当中央仓库的Git仓库挂了，你可以随时创建一个新的中央库然后同步就立刻恢复了中央库。
初始操作
为自己的机器注册全局 name 和 email，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
初始化：把本地目录变成Git可以管理的仓库，会生成一个隐藏的.git目录
git init
托管：将文件添加到本地仓库，托管(跟踪 track)起来，添加到了暂存区。
git add readme.txt # 将 readme.txt这个文件添加到本地仓库
git add . # 将当前目录下的所有文件添加到本地仓库
提交：将改动提交到仓库，生成一个版本
git commit -m "本次提交的描述" # 描述主要用来记录做了什么，方便记录和查找。
版本操作
git status : 命令可以让我们时刻掌握仓库当前的状态，是否有改动
-
Changes not staged for commit: 未准备提交的更改，即有修改但是未add到暂存区
-
Changes to be committed: 有改动需要提交，即暂存区有修改但是未commit
-
nothing to commit, working tree clean： 当前没有需要提交的修改，而且，工作目录是干净的
git diff <filename>：命令可以查看被修改的文件，具体修改了哪些内容
本地版本回退（重置）
场景：每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照（版本）在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把之前的工作成果全部丢失。
git log： 查看git的提交历史
git log --pretty=oneline： 将历史记录单行展示以便查看
可以查看每次commit的commit_id（版本号），是一个hash值，在使用的时候可以一般只取前7位
git reset --hard HEAD^ # 将本地版本重置到上一次commit
git reset --hard 1094a12 # 将本地版本重置到指定版本，可以往前也可以往后
场景：当你重置之后，后悔了又想恢复到之前的新版本，可能会找不到新版本的commit_id，这时候可以使用git relog 查看git的命令历史 ，找到最新版本的commit_id。
git reflog # 查看命令历史找到commit id
git reset --hard commit_id
版本回滚 （git revert）
版本回滚用来对之前的某一次提交前行一次逆操作，并形成一次新的commit，版本号是往前推动。
如果节点树是这样：commit_A - commit_B - commit_C ，如果使用 git reset –hard HEAD^ ，重置到上一次的提交，那么节点树将会变成commit_A - commit_B，此时commit_C的修改会变成未提交状态。
如果使用git revert ，那么节点树会变成 commit_A - commit_B - commit_C - commit_D，此时commit_D其实是与commit_B之后保持一样的，git revert相当于是对commit_C做了一次逆操作，例如commit_C在commit_B的基础了增加了a.txt，而这次commit_D就相当于是删除了a.txt在做了一次提交。
git revert使用场景是在，你本地的master分支与远程的master分支一直保持一致，但是，你提交了一次错误的commit，并且push到了远程的master分支，如果此时你本地使用git reset 重置了这次提交，但是远程分支上的这次提交还是存在的，这时候，你本地分支将落后远程master一个版本，无法在提交新的push；当然你可以在远程仓库中重置这次提交，在多人协助时这是有风险的， 并且这需要远程库的owner来操作，所以这时候，你可以使用git revert 来逆转这次提交，并形成一个新的commit，然后push到远程master上，推动远程master也逆转这次操作，这对于远程master来说，只是一次新的push，版本号继续往前滚，但是内容是回退的。
git revert的操作相当于是 手动将一次提交改成提交前的样子再push。当然也可以逆转之前的任何一次commit，不一定是上一次的。
场景：节点树commit_A - commit_B - commit_C，比如你发现commit_B是错误一次提交，但是commit_C是正确的，需要保留的，也可以只单独逆转commit_B的操作，但是可能会存在和commit_C和commit_B修改的是同一个文件，在逆转后，可能会出现代码逻辑错误，需要开发人员去仔细查看并修改。
git revert # 逆转上一次的提交
git revert commit_id # 逆转指定的提交
# commit链 A-B-C-D-E
git revert B..E # 前开后闭 逆转了C-D-E的操作
git revert B^..E # 逆转了B-C-D-E的操作
1、合并的操作一般包含两个commit，代表是从哪两个commit合并过来的，当只需要逆转其中一次的commit，则可以使用-m 参数。参考：逆转merge的commit。 2、一次逆转多次提交只产生一次从commit，使用-n参数，参考：git revert多个提交
工作区和暂存区
工作区就是你在电脑里能看到的目录，工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库，Git的版本库里存了很多东西，其中最重要的就是称为stage的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
git add把文件添加进去，实际上就是把文件修改添加到暂存区；
git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支
你可以简单理解为，add的时候将需要提交的文件修改通通放到暂存区，然后，commit的时候一次性提交暂存区的所有修改。
管理修改
为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
场景：第一次修改 -> git add -> 第二次修改 -> git commit
第二次修改不会被提交，因为没有被添加到暂存区中，commit只会将暂存区的修改提交生成一个版本，这个时候，使用命令git status可以看到 Changes not staged for commit: 未准备提交的更改，即有修改但是未add到暂存区。
git commit –amend
git commit –amend 用来修改 commit。
1、如果你只想修改上一个 commit 的 message。
git commit --amend
# 就会出现上一次的 commit 信息，进入 vim 编辑模式修改即可 然后 :wq
2、如果上一次的修改，你遗漏了某些更改。
# 直接修改遗漏的修改 然后
git add a.txt
git commit --amend
# 是否需要修改 commit message 如果不需要 直接 :wq
# 关于 a.txt 的最新改动会和上一次 commit 合并
# 如果已经前面的修改 push 了，这一步之后应该 使用 push -f
撤销修改
git checkout -- file可以丢弃工作区的修改。 – 非常重要，没有–，就变成了“切换到另一个分支”的命令。
修改后还没有被放到暂存区，现在，撤销修改就回到和当前版本库一模一样的状态；
已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态，就是git add 之后的状态。
场景：修改只是添加到了暂存区，还没有提交
用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区。
删除文件，删错了，也可以使用git checkout -- file恢复过来，因为删除也算是一种修改。
注意: 从来没有被添加到版本库就被删除的文件，是无法恢复的！
远程仓库
远程仓库用于托管代码，每个人每台机器都能从这个仓库中克隆一份代码到本地电脑中，也可以将各自的提交推送到远程仓库中，也可以从远程仓库中拉取别人的修改。
使用GitHub托管代码
1、创建SSH Key，因为你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的。
使用命令ssh-keygen -t rsa -C "youremail@example.com"，有需要设立密码的操作，可忽略。
如果一切顺利，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
将id_rsa.pub中的内容添加到GitHub中的Account settings中。
GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
本地仓库关联远程仓库
git remote add origin git@github.com:xxx/xx.git
本地仓库取消关联远程仓库
git remote remove origin
也可以直接删除目录从.git目录
把本地库的所有内容推送到远程库上
git push -u origin master
git push origin master # 关联之后的推送
git push origin dev:dev # 将本地dev分支推送到origin并创建origin/dev分支 （远程没有dev分支）
git push origin dev -f # 强推 使用本地分支强行覆盖远程dev分支
-u 参数指本次推送不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告，这是因为SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。 如果你当心有人冒充GitHub服务器，可以到GitHub的RSA Key的指纹信息验证是否一致
从远程库克隆
git clone git@github.com:xxx/xx.git