简单玩git

最新推荐文章于 2023-02-07 14:38:20 发布

吃骨头不吐股骨头皮

最新推荐文章于 2023-02-07 14:38:20 发布

阅读量243

点赞数

分类专栏： git Android学习总结文章标签： git常用命令的尝试 git

本文链接：https://blog.csdn.net/u013855006/article/details/100831541

版权

Android学习总结同时被 2 个专栏收录

39 篇文章 3 订阅

订阅专栏

git

1 篇文章 0 订阅

订阅专栏

Git介绍

不管以前是否使用过git，其实现在都可以开始了解学起来，下面的介绍就引用维基百科的介绍，有兴趣的可以看一下。

Git是什么？具体干什么的？
git（/ɡɪt/）是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL发布。最初目的是为更好地管理Linux内核开发而设计。应注意的是，这与GNU Interactive Tools[5]（一个类似Norton Commander界面的文件管理器）有所不同。
git最初的开发动力来自于BitKeeper和Monotone。git最初只是作为一个可以被其他前端（比如Cogito或Stgit）包装的后端而开发的，但后来git内核已经成熟到可以独立地用作版本控制。很多著名的软件都使用git进行版本控制，其中包括Linux内核、X.Org服务器和OLPC内核等项目的开发流程。

主要功能？
git是用于Linux内核开发的版本控制工具。与CVS、Subversion一类的集中式版本控制工具不同，它采用了分布式版本库的作法，不需要服务器端软件，就可以运作版本控制，使得源代码的发布和交流极其方便。git的速度很快，这对于诸如Linux内核这样的大项目来说自然很重要。git最为出色的是它的合并追踪（merge tracing）能力。
git更像一个文件系统，直接在本机上获取数据，不必连线到主机端获取数据。每个开发者都可有全部开发历史的本地副本，changes从这种本地repository复制给其他开发者。这些changes作为新增的开发分支被导入，可以与本地开发分支合并。
分支是非常轻量级的，一个分支仅是对一个commit的引用。
git是用C语言开发的，以追求最高的性能。git自动完成垃圾回收，也可以用命令git gc --prune直接调用。
git存储每个新创建的object作为一个单独文件。为了压缩存储空间占用， packs操作把很多文件（启发式类似名字的文件往往具有类似内容）使用差分压缩入一个文件中（packfile），并创建一个对应的索引文件，指明object在packfile中的偏移值。新创建的对象仍然作为单独文件存在。repacks操作非常费时间，git会在空闲时间自动做此操作。也可用命令git gc来直接启动repack。packfile与索引文件都用SHA-1作为校验和并作为文件名。git fsck命令做校验和的完整性验证。

生成提交记录
git commit
git commit -m “具体的提交内容”
git commit -a 会打开vim或者nano的编辑器，编辑具体的提交内容
创建分支
Git 的分支也非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。只要记住使用分支其实就相当于在说：“我想基于这个提交以及它所有的父提交进行新的工作。”
创建分支：git branch <你的分支名>
切换分支：git checkout <你的分支名>
删除本地分支：git branch <本地分支名> -D或者git branch -d <本地分支>
上面两步等同于下面这一步
创建并切换分支：git checkout -b <你的分支名>

开发中可能会更多的遇到这种，远程分支已经存在，我们本地没有对应的分支
查看所有分支：git branch --all或者git branch -a
创建并切换分支：git checkout <远程分支> -b <你的分支名>
分支合并
第一种方式：git merge <需要合并的分支>，在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”

git merge --no-ff -m “添加合并信息” dev ：–no-ff参数，表示禁用Fast forward
合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

比如：有两个分支maser和dev，现在需要把dev分支的内容合并到master，我们需要切换到master(git checkout master)，然后执行 git merge dev，将dev分支的内容合并到master。

第二种方式：git rebase，Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。Rebase 的优势就是可以创造更线性的提交历史，看起来是线性的，真实其实是并行开发的。
在提交树上移动
HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。
HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。
相对引用
通过指定提交记录哈希值的方式在 Git 中移动不太方便。需要用 git log 来查查看提交记录的哈希值。哈希值在真实的 Git 世界中也会更长（注：基于 SHA-1，共 40 位），Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。
第一种：使用 ^ 向上移动 1 个提交记录
例如master：git checkout master^
拆分：git checkout HEAD，git checkout HEAD^

第二种：使用 ~< num> 向上移动多个提交记录，如 ~3
使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:
git branch -f master HEAD~3，上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。
例子
撤销变更
在 Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。我们主要关注的是后者。
第一种：git reset
git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。
我们可以使用git log查看提交记录，git log --pretty=oneline查看简化的记录
git reset HEAD^(HEAD~1)，撤销的是本地提交
git reset --hard (commitId)，回退当前版本到指定的commitId，git 只是在移动HEAD指针。（这里不仅可以回退到以前的，也可以从以前的版本回退到最近的，只要知道commitId）
git reset --hard HEAD^，回退当前版本到上一个版本
如果我们关闭了终端，找不到commitId了，git给我们提供了git reflog来记录我们的每一次操作，是不是很智能。

第二种：git revert
为了撤销更改并分享给别人，我们需要使用 git revert。
好玩的是git revert会在我们要撤销的提交记录后面多一个新提交，这是因为新提交记录 C2’ 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2’ 的状态与 C1 是相同的。
git revert HEAD
整理提交记录
如果知道提交的哈希值，git cherry-pick <提交号>，如果你想将一些提交复制到当前所在的位置（HEAD）下面的话， Cherry-pick 是最直接的方式了。
交互式的 rebase
但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了

交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i

如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。

当 rebase UI界面打开时, 你能做3件事:
1、调整提交记录的顺序（通过鼠标拖放来完成）
2、删除你不想要的提交（通过切换 pick 的状态来完成，关闭就意味着你不想要这个提交记录）
3、合并提交。
git rebase -i HEAD~4
本地栈式提交
在开发中经常会遇到的情况：我正在解决某个特别棘手的 Bug，为了便于调试而在代码中添加了一些调试命令并向控制台打印了一些信息。这些调试和打印语句都在它们各自的提交记录里。
最后把 dev分支里的工作合并回 master 分支了。你可以选择通过 fast-forward 快速合并到 master 分支上，但这样的话 master 分支就会包含我这些调试语句了。
其实就是通过：git cherry-pick <提交哈希值>合并我们需要的代码
提交的技巧
1、你之前在 newImage 分支上进行了一次提交，然后又基于它创建了 caption 分支，然后又提交了一次。此时你想对的某个以前的提交记录进行一些小小的调整。比如设计师想修改一下 newImage 中图片的分辨率，尽管那个提交记录并不是最新的了。
可以通过下面的方法来克服困难：
先用 git rebase -i 将提交重新排序，然后把我们想要修改的提交记录挪到最前
然后用 commit --amend 来进行一些小修改
接着再用 git rebase -i 来将他们调回原来的顺序
最后我们把 master 移到修改的最前端（用你自己喜欢的方法），就大功告成啦！

2、要在心里牢记 cherry-pick 可以将提交树上任何地方的提交记录取过来追加到 HEAD 上（只要不是 HEAD 上游的提交就没问题）。

git checkout master
git cherry-pick c2
git commit --amend
git cherry-pick c3
git tag
分支很容易被人为移动，并且当有新的提交时，它也会移动。分支很容易被改变，大部分分支还只是临时的，并且还一直在变。
你可能会问了：有没有什么可以永远指向某个提交记录的标识呢，比如软件发布新的大版本，或者是修正一些重要的 Bug 或是增加了某些新特性，有没有比分支更好的可以永远指向这些提交的方法呢？
Git 的 tag 就是干这个用的啊，它们可以（在某种程度上 —— 因为标签可以被删除后重新在另外一个位置创建同名的标签）永久地将某个特定的提交命名为里程碑，然后就可以像分支一样引用了。更难得的是，它们并不会随着新的提交而移动。你也不能检出到某个标签上面进行修改提交，它就像是提交树上的一个锚点，标识了某个特定的位置。

git tag <tag名> <指向节点哈希值>
如果在当前分支，直接使用git tag <tag名>
git show <tag名> 查看标签信息

可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
git tag -a <tag名> -m “tag信息” <节点哈希值>：哈希值就是commitId
git tag 查看所有标签
git tag -d <tag名> ，删除标签，因为创建的标签都只存储在本地，不会自动推送到远程，所以可以安全的删除。
git push origin <tag名>，将指定标签的内容推送到远程仓库
git push origin --tags，一次性推送全部尚未推送到远程的本地标签

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
git tag -d <tag名>
从远程删除：
git push origin :refs/tags/<tag名>

注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
Git Describe
由于标签在代码库中起着“锚点”的作用，Git 还为此专门设计了一个命令用来描述离你最近的锚点（也就是标签），它就是 git describe！Git Describe 能帮你在提交历史中移动了多次以后找到方向；当你用 git bisect（一个查找产生 Bug 的提交记录的指令）找到某个提交记录时，或者是当你坐在你那刚刚度假回来的同事的电脑前时，可能会用到这个命令。

git describe 的语法是：
git describe < ref>，< ref> 可以是任何能被 Git 识别成提交记录的引用，如果你没有指定的话，Git 会以你目前所检出的位置（HEAD）。
它输出的结果是这样的：< tag>_< numCommits>_g< hash>
1、tag 表示的是离 ref 最近的标签， numCommits 是表示这个 ref 与 tag 相差有多少个提交记录， hash 表示的是你所给定的 ref 所表示的提交记录哈希值的前几位。
2、当 ref 提交记录上有某个标签时，则只输出标签名称

具体示例：
git describe

多分支 rebase
希望得到有序的提交历史，也就是我们最终的结果应该是 C6’ 在 C7’ 上面， C5’ 在 C6’ 上面，依此类推。不要担心，即使你搞砸了也没关系，用 reset 命令就可以重新开始了。
就是按照顺序从最开始的依次的rebase
选择父提交记录
操作符 ^ 与 ~ 符一样，后面也可以跟一个数字。
但是该操作符后面的数字与 ~ 后面的不同，并不是用来指定向上返回几代，而是指定合并提交记录的某个父提交。还记得前面提到过的一个合并提交有两个父提交吧，所以遇到这样的节点时该选择哪条路径就不是很清晰了。
Git 默认选择合并提交的“第一个”父提交，在操作符 ^ 后跟一个数字可以改变这一默认行为。
我们也可以把分支强行切回到某个节点：
git branch -f master HEAD~^2 ~2，后面是连着写的，因为MarkDownpad的问题我才故意隔开的。
纠缠不清的分支
现在我们的 master 分支是比 one、two 和 three 要多几个提交。出于某种原因，我们需要把 master 分支上最近的几次提交做不同的调整后，分别添加到各个的分支上。
one 需要重新排序并删除 C5，two 仅需要重排排序，而 three 只需要提交一次。
这里最优的5步就可以解决，我这里用了八步，O(∩_∩)O哈哈~，大家弄出最优的步骤可以放在评论去一起讨论学习
远程仓库
远程仓库并不复杂, 在如今的云计算盛行的世界很容易把远程仓库想象成一个富有魔力的东西, 但实际上它们只是你的仓库在另个一台计算机上的拷贝。你可以通过因特网与这台计算机通信 —— 也就是增加或是获取提交记录

远程仓库的两个特性：
1、首先也是最重要的的点, 远程仓库是一个强大的备份。本地仓库也有恢复文件到指定版本的能力, 但所有的信息都是保存在本地的。有了远程仓库以后，即使丢失了本地所有数据, 你仍可以通过远程仓库拿回你丢失的数据。
2、还有就是, 远程让代码社交化了! 既然你的项目被托管到别的地方了, 你的朋友可以更容易地为你的项目做贡献(或者拉取最新的变更)
现在用网站来对远程仓库进行可视化操作变得越发流行了(像 Github 或 Phabricator), 但远程仓库永远是这些工具的顶梁柱

git clone 在本地创建一个远程仓库的拷贝
我们平常使用：git clone <远程仓库的地址>

远程分支

1、注意到的第一个事就是在我们的本地仓库多了一个名为 o/master 的分支, 这种类型的分支就叫远程分支，远程分支反映了远程仓库(在你上次和它通信时)的状态。
2、远程分支有一个特别的属性，在你检出时自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。

为什么有 o/？
你可能想问这些远程分支的前面的 o/ 是什么意思呢？好吧, 远程分支有一个命名规范 —— 它们的格式是:
< remote name>/< branch name>
因此，如果你看到一个名为 o/master 的分支，那么这个分支就叫 master，远程仓库的名称就是 o。
大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了

Git Fetch
Git 远程仓库相当的操作实际可以归纳为两点：向远程仓库传输数据以及从远程仓库获取数据。
你会看到当我们从远程仓库获取数据时, 远程分支也会更新以反映最新的远程仓库。

git fetch 做了些什么?
git fetch 完成了仅有的但是很重要的两步:
1、从远程仓库下载本地仓库中缺失的提交记录
2、更新远程分支指针(如 origin/master)
git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。
远程分支反映了远程仓库在你最后一次与它通信时的状态，git fetch 就是你与远程仓库通信的方式了！
git fetch 通常通过互联网（使用 http:// 或 git:// 协议) 与远程仓库通信。

git fetch不会做的事情
git fetch 并不会改变你本地仓库的状态。它不会更新你的 master 分支，也不会修改你磁盘上的文件。

Git Pull，更新远程库中的数据
当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支
例如：
git cherry-pick origin/master
git rebase origin/master
git merge origin/master

通过测试证明：git pull 就是 git fetch 和 git merge < just-fetched-branch> 的缩写！
git pull 就是两步，先git fetch拉取远程库最新数据，然后将远程分支(origin/master)的内容merge到本地分支，这里说明下远程分支名并不一定是master哈，这个要看你远程库中有多少分支，其实都是远程分支，哈哈。
Git Push，提交你本地的修改到远程仓库
注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本
git push origin <本地分支名>:<远程分支名>
注意，分支推送顺序的写法是<来源地>:<目的地>，所以git pull是<远程分支>:<本地分支>，而git push是<本地分支>:<远程分支>。

1、如果省略远程分支名，则表示将本地分支推送与之存在"追踪关系"的远程分支（通常两者同名），如果该远程分支不存在，则会被新建。
git push origin master表示将本地master分支上的代码推送到远程仓库的master分支上

2、如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支。
git push origin :master等同于git push origin --delete master，表示删除远程仓库上的master分支。
我们平时的开发中一定要记住，先pull，然后在push
实际开发配合
假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 —— 天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。
因为这情况（历史偏离）有许多的不确定性，Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码，然后才能分享你的工作。
第一种：
1、git fetch 将远程库的更新，更新下来
2、git rebase origin/master ，origin/master代表你的当前开发分支的远程分支，不一定是master，将本地分支代码和远程分支的代码合并
3、git push 将本地最新代码推动到远程仓库
第二种：
1、git fetch
2、git merge origin/master 将远程分支的最新更细合并到本地分支
3、git push
第三种：
git pull是git fetch和git merge的结合，git pull --reabase是git fetch和git merge的结合
实际的操作中，看具体需求git pull配合git push，或者git pull --rebase配合git push

注意：比较常遇到的问题，我们经常在pull的时候会告诉你远程仓库的代码跟你本地有冲突，我们可以先git add . ，然后git commit，然后git pull将代码拉下来，然后用git status .查看有哪些冲突文件（报红），然后在本地解决冲突。
某些文件冲突太多：我们先使用git reset配合git checkout将冲突文件回退，然后在对比我们具体的修改，添加上去
git reset app/src/main/java/com/sisisan/batmessage/activity/GroupSubjectActivity.java(冲突文件)
git checkout app/src/main/java/com/sisisan/batmessage/activity/GroupSubjectActivity.java
合并特性分支
合并一些复杂的分支，注意好好运用上面的合并代码的一些命令
合并分支的时候，rebase和merge根据具体需求具体使用
rebase 的优缺点：
优点:
Rebase 使你的提交树变得很干净, 所有的提交都在一条线上
缺点：
Rebase 修改了提交树的历史
比如, 提交 C1 可以被 rebase 到 C3 之后。这看起来 C1 中的工作是在 C3 之后进行的，但实际上是在 C3 之前。

merge跟rebase刚好相反，可以保留提交历史，但是提交数不在同一条线上，看着没有那么干净。
我个人更喜欢merge。仁者见仁，智者见智了，^_
远程跟踪分支
pull 操作时, 提交记录会被先下载到 origin/master 上，之后再合并到本地的 master 分支。隐含的合并目标由这个关联确定的。

push 操作时, 我们把工作从 master 推到远程仓库中的 master 分支(同时会更新远程分支 origin/master) 。这个推送的目的地也是由这种关联确定的！

1、直接了当地讲，master 和 origin/master 的关联关系就是由分支的“remote tracking”属性决定的。master 被设定为跟踪 origin/master —— 这意味着为 master 分支指定了推送的目的地以及拉取后合并的目标。当你git clone的时候，git就自动帮你设定好了。

2、当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 origin/master）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 master。
当你git clone的时候会看到local branch “master” set to track remote branch "origin/master"

自己设定这个属性：
第一种：git checkout -b <本地分支> <远程分支>
例如：git checkout -b dev origin/devlopement，就是新建一个名为dev的分支，跟踪远程分支origin/developement
第二种：git branch -u <远程分支> <本地分支>
例如：git branch -u origin/dev dev，这样dev分支就会跟中origin/dev，如果当前在dev分支，还可以省略dev，git branch -u origin/dev。这种情况需要本地已经有一个本地分支，例如我本地分支dev是从远程分支origin/dev拉出来的，我现在想直接往origin/master提交代码，我就可以使用上述命令，让本地分支dev去跟踪远程仓库的分支origin/master。
git push的参数

语法一：git push < remote> < place>
例如：git push origin master，翻译过来就是：
1、切到本地仓库中的“master”分支，获取所有的提交，再到远程仓库“origin”中找到“master”分支，将远程仓库中没有的提交记录都添加上去。
2、我们通过“place”参数来告诉 Git 提交记录来自于 master, 要推送到远程仓库中的 master。它实际就是要同步的两个仓库的位置。

语法二：要同时为源和目的地指定 < place> 的话，只需要用冒号 : 将二者连起来就可以了：
git push origin < source>:< destination>
这个参数实际的值是个 refspec，“refspec” 是一个自造的词，意思是 Git 能识别的位置（比如分支 foo 或者 HEAD~1）
git push origin master:master

Git fetch 的参数
语法一：git fetch < remote> <远程分支>
例如：git fetch origin master，会从远程分支master上获取本地不存在的提交，放在origin/master

你可能会好奇 —— 为何 Git 会将新提交放到 o/foo 而不是放到我本地的 foo 分支呢？之前不是说这样的 < place> 参数就是同时应用于本地和远程的位置吗？
Git 做了一些特殊处理，因为你可能在 foo 分支上的工作还未完成，你也不想弄乱它。它不会更新你的本地的非远程分支, 只是下载提交记录（这样, 你就可以对远程分支进行检查或者合并了）。

语法二：git fethc origin < source>:< destination>
source 现在指的是远程仓库中的位置，而 < destination> 才是要放置提交的本地仓库的位置。它与 git push 刚好相反。
如果你觉得直接更新本地分支很爽，那你就用冒号分隔的 refspec 吧。不过**，你不能在当前所在的分支上干这个事，但是其它分支是可以的。**
注意：这里如果目标分支不存在跟git push一样，会创建一个目标分支，不同的是git push是在远程仓库创建目标分支，git fetch是在本地创建目标分支。

例如：你当前在dev分支，你不能git fetch origin dev:developement，但是可以git fetch origin master:master。
例子：git fetch origin foo:master，git fetch origin master~:foo
push或者fetch省略源
在 git push 或 git fetch 时不指定任何 source，方法就是仅保留冒号和 destination 部分，source 部分留空。
git push origin :<远程仓库目标分支>：git push origin :master，会删除远程仓库的master分支
git fetch origin :<本地目标分支>：git fetch origin :dev，会在本地创建一个dev的新分支

看到上面fetch的套路是不是想砸键盘，O(∩_∩)O哈哈~，太狠了，竟然跟push不一样
git pull加参数
git pull本身就是，git fetch和git merge的结合
git pull origin foo就相当于：git fetch origin foo；git merge origin/foo

git pull origin bar~1:foo就相当于：git fetch origin bar ~:foo；git merge foo
git pull 实际上就是 fetch + merge 的缩写, git pull 唯一关注的是提交最终合并到哪里（也就是为 git fetch 所提供的 destination 参数）

例子：例如我当前所在分支是master*，git pull origin bar:foo，拆解就是git fetch origin bar:foo：将bar上的更新拉到本地的foo分支上，然后执行git merge foo：将分支foo上的更新合并到master
1. git diff
  可以查看当前修改了哪些东西
  git diff HEAD – readme.txt命令可以查看工作区和版本库里面最新版本readme.txt的区别
2. 撤销修改
  git checkout – (file)，可以撤销工作区的修改
  例如：git checkout – readme.txt
  一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
  一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
git reset HEAD < file>可以把暂存区的修改撤销掉，重新放回工作区。
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
1. 删除文件
  rm <文件> 删除无用的文件
  git rm <文件> 从版本库中删除该文件
  
  另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本： git checkout – <文件>
  
  先手动删除文件，然后使用git rm < file>和git add< file>效果是一样的。
2. 添加本地库到远程库
  git remote add origin git@github.com:michaelliao/learngit.git< git库地址>
  git push -u origin master 推送内容并且将远程仓库和本地仓库关联，只有第一次推送需要-u
  然后下一次就可以使用 git push origin master提交代码
  
  前面我们有一个命令：git branch -u <远程仓库的远程分支> <本地分支>，就是将本地分支跟踪到远程分支。
3. 最新的切换分支方法
  git switch -c dev：创建并切换分支到dev
  git switch master：切换分支
4. git log
  git log 查看日志
  git log --pretty=oneline 查看简化的日志
  git log --graph 查看分支合并图
  git log --graph --pretty=oneline --abbrev-commit
5. git stash
  我们平时开发的时候经常会遇到这种问题，比如我们正在做一个功能，还没做完，我们又需要修复紧急bug，我们希望功能做完之后再提交。
  所以Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：git stash，然后我们再切换到需要修改bug的分支去修改bug。
  bug修复完成之后我们可以使用：
  第一种：git stash apply恢复，然后使用git stash drop删除stash内容。
  第二种：git stash pop，恢复的同时把stash内容删除
  
  git stash list，查看stash列表
  你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
  git stash apply stash@{0}
  
  如果我们需要将修复的bug在开发分支也有，直接git cherry-pick commitId
6. git remote或者git remote -v查看远程库信息
7. git branch --set-upstream branch-name origin/branch-name，建立本地分支和远程分支的关联，还可以使用git branch -u origin/branch-name branch-name：建立本地分支和远程分支的跟踪。如今最新的命令，建立本地分支和远程分支关联git branch --set-upstream-to=origin/远程分支名