git clone 仓库地址
git add .
git status
git commit -m"提交说明"
git pull origin develop
git push origin develop
平时拉取代码提交代码只用过这几条命令，虽然够用，但我并不清楚具体是啥意思，于是系统学习一下Git命令并总结。
什么是Git：分布式版本控制系统
初始化一个git仓库（将目录变成git可管理的系统）
git init
添加文件到git系统
1. git add <file>把文件添加到仓库,可反复多次使用，添加多个文件
2. git commit -m <message>把文件提交到仓库
1 file changed：一个文件被改动 1 insertions：插入了两行内容 1 deletion：删除一行内容
时刻掌握仓库当前状态
git status
查看具体修改的内容
git diff
版本回退
显示从最近到最远的提交日志
git log
HEAD表示当前版本
上一个版本:HEAD^ ,上上一个版本：HEAD^^,往上100个版本:HEAD~100
简洁显示
--pretty=oneline
返回格式：版本号 提交说明
回退版本
git reset
将当前版本回退到上个版本
git reset —hard HEAD^
将当前版本回退到指定版本
git reset —hard commit_id(版本号前几位即可，git会自动去找)
版本号通过git log找
回退速度快：Git仅仅改变HEAD指向
查看命令历史
git reflog
💥工作区和暂存区
工作区
- 电脑能看到的目录
版本库：.git
-
其中最重要的是称为stage的暂存区，还有git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD
-
git add实际上是把文件修改添加到暂存区
- git commit 实际上是把暂存区的所有内容提交到当前分支
-
因为git自动为我们创建了唯一一个master分支，所以现在是往master分支上提交修改
-
可以简单理解为：需要提交的文件修改统统放到暂存区，然后一次性提交暂存区的所有修改
只有理解这部分，之后的内容才能顺利理解
管理修改
为什么Git比其他版本控制系统设计得优秀？
因为Git跟踪并管理的是修改，而非文件。
什么是修改?
比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。
Git是如何跟踪修改
先git add到暂存区，再加入到commit中。
撤销修改
丢弃工作区的修改
情况一：文件修改都在工作区，没有提交到暂存区
git checkout -- file让这个文件回到最近一次git commit或git add时的状态
git checkout -- file 命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令
情况二：已经使用add提交到暂存区，但是没有使用commit提交到版本库
1. 撤销暂存区的修改（unstage），重新放回工作区
-
git reset HEAD <file> -
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本
2. 丢弃工作区的修改
git checkout -- file还原工作区（文件内容）
情况三：已经从暂存区提交到了版本库
- 使用
git reset HEAD <file>版本回退
情况四： 已经提交推送到远程版本库
- 没救了
删除文件
添加一个文件到Git后提交，并且在文件管理器或用rm删了这个文件
Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
情况一：删错了，需要把误删的文件恢复到最新版本
git checkout -- <file>
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
情况二：确实要从版本库中删除该文件
git rm <file>删除文件git commit -m <message>提交修改
远程仓库
添加远程库
由于最近项目用的是GitLab，这里也是用GitLab做示例，并且假设已经在GitLab中建立了仓库。现在的需求是想让本地Git仓库和GitLab的Git仓库进行远程同步。
1. 获取项目地址(之前要导入过SSH key)
2. 关联本地Git仓库和GitLab的Git仓库
在本地仓库下运行git remote add origin 仓库地址
3. 把本地库的所有内容推送到远程库上
git push -u origin master
在GitLab上可以看见推送消息
把本地库的内容推送到远程，用
git push命令，实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送
master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。之后，只要只要本地作了提交，就可以通过命令：
git push origin master把本地master分支的最新修改推送至GitLab
删除远程库
1. 先用git remote -v查看远程库信息
2. 用git remote rm <name> 删除远程库
根据名字删除，比如删除origin：git remote rm origin
此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitLab，在后台页面找到删除按钮再删除。
从远程库克隆
上一种情况是先有本地库，后有远程库的时候，如何关联远程库。
现在是先有远程库，然后从远程库克隆。
用命令git clone克隆一个本地库
进目录里看，已经有远程库里的README.md文件了
分支管理
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
在版本回退里已经知道，每次提交，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分支：
创建与合并分支
1. 创建dev分支并切换到dev分支：
git checkout -b dev
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：git branch devgit checkout dev2. 查看当前分支
git branch
3. 把dev分支的工作成果合并到master分支
先git checkout master切换到master分支
再git merge dev
删除分支
git branch -d 分支名
查看分支
git branch
switch
我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。
实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：
创建并切换到新的dev分支
git switch -c dev
直接切换到已有的master分支
git switch master
解决冲突
假设master分支和feature1分支各自都修改了同一个文件并且分别有新的提交
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突
git status可以告诉我们冲突的文件：
查看readme.txt的内容:
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容
修改后再次提交:
用带参数的git log也可以看到分支的合并情况:
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用
git log --graph命令可以看到分支合并图。
Bug分支
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是当前正在dev上进行的工作还没有提交,并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办?
Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支
修复bug，然后在这个临时分支提交
修复完成后，切换到master分支，并完成合并，最后删除临时分支
切换到回到dev分支继续干活
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin
查看远程库的信息
git remote
查看更详细信息
git remote -v
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上
git push origin 分支名
- 查看远程库信息，使用
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，如果有冲突，要先处理冲突。
标签管理
发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。
tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起,比起找一串字符组成的commit号更方便
创建标签
1. 切换到需要打标签的分支上
2. 打一个新标签
git tag <name>
查看所有标签
git tag
给之前的commit打标签
默认标签是打在最新提交的commit上的,想要给之前的commit打标签，需要用git log 找到历史提交的commit id，然后打上标签
git tag 标签名 commit号
创建带有说明的标签
git tag -a 标签名 -m "说明" commit号
查看详细标签信息
git show <tagname>
操作标签
推送标签到远程
git push origin <tagname>
一次性推送全部尚未推送到远程的本地标签
git push origin --tags
删除创建但未推送到远程的标签
git tag -d 标签名
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
删除推送到远程的远程标签
- 先从本地删除
git tag -d 标签名
- 然后，从远程删除
git push origin :refs/tags/<tagname>
结束
过了一遍文档，尤其是工作区和暂存区那部分，让我理解了平时用的那几条命令到底啥意思。学到很多Git命令，对Git了解也更加深入了。
