4.Git 进阶
4.1用户名和邮箱
每一次commit都会产生一条log，==log标记了提交人的姓名与邮箱==，以便其他人方便的查看与联系提交人，所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱。执行以下代码：
git config —global user.name “stormzhang”
git config —global user.email “stormzhang.dev@gmail.com”
以上进行了==全局配置==，当然有些时候我们的某一个项目想要用特定的邮箱，这个时候只需切换到你的项目，以上代码把 —global 参数去除，再重新执行一遍就ok了。
PS：我们在 GitHub 的每次提交理论上都会在 主页的下面产生一条绿色小方块的记录，如果你确认你提交了，但是没有绿色方块显示，那肯定是你提交代码配置的邮箱跟你 GitHub 上的邮箱不一致，GitHub 上的邮箱可以到 Setting -> Emails里查看）
4.2 alias设置别名
*频繁执行一些Git命令非常繁琐，使用alias可以配置别名
git config --global alias.co checkout # 别名
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
这样原本的命令
git commit
git checkout
git branch
git status
就变成了：
git c
git co
git br
git s
每个人别名可以设置的不一样。除此之外还可以设置组合，比如：
git config --global alias.psm 'push origin master'
git config --global alias.plm 'pull origin master'
之后就直接就用==git psm==代替 git push origin master，==git plm== 代替git pull origin master。
输入git log —graph —pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ —abbrev-commit —date=relative 查看日志会变成：
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%
d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"
输入以上命令之后，输入==git lg==就可以了。
4.3 其他配置
默认情况下 git 用的编辑器是 vi ，可以改成vim 。
git config --global core.editor "vim" # 设置Editor使用vim
git config --global color.ui true#给Git着色
git config --global core.quotepath false # 设置显示中文文件名
默认这些配置都在 ~/.gitconfig 文件下的，你可以找到这个文件查看自己的配置，也可以输入 git config -l 命令查看
4.4 查看改动 diff
比如我有一个 a.md 的文件，我现在做了一些改动，然后输入 git diff 就会看到如下：
红色的部分前面 - 代表删除的，绿色的部分前面 + 代表增加的，一目了然。
==直接输入 git diff 只能比较当前文件和暂存区文件差异==（暂存区就是还没有执行 git add 的文件）。还可以执行以下命令：git diff <$id1> <$id2> # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较
git diff --staged # 比较暂存区和版本库差异
4.5 checkout切换分支、tag，撤销文件
1.checkout 切换分支：
git checkout develop#切换到devlop分支
2.也可以用来切换tag，切换到某次commit，如：git checkout v1.0
git checkout ffd9f2dd68f1eb21d36cee50dbdd504e95d9c8f7 # 后面的一长串是commit_id，是每次commit的SHA1值，可以根据 git log 看到。
3.checkout 撤销还原文件
举个例子，假设我们在一个分支开发一个小功能，刚写完一半，这时候需求变了，而且是大变化，之前写的代码完全用不了了，好在你刚写，甚至都没有 git add 进暂存区，这个时候很简单的一个操作就直接把原文件还原：
git checkout a.md
这里稍微提下，==checkout 命令只能撤销还没有 add 进暂存区的文件。==
4.6. stash紧急修改bug
因为某些原因，需要暂时切到别的分支，紧急修复bug。修改完再切回来，但是现在的代码也要能保留。
这个时候 stash 命令就大有用处了，前提是我们的代码没有进行 commit ，哪怕你执行了add 也没关系，我们先执行:
git stash#把当前分支所有没有 commit 的代码先暂存起来
这个时候你再执行 git status 你会发现当前分支很干净，几乎看不到任何改动，你的代码改动也看不见了，但其实是暂存起来了。执行git stash list你会发现此时暂存区已经有了一条记录。
这个时候你可以切换其他分支，赶紧把bug修复好。改完再切换回来：
git stash list #查看暂存区记录
git stash apply #还原之前暂存的代码
git stash drop #把最近一条的 stash 记录删除了，最好这么做
git stash pop #上面两个的组合，还原代码，并自动删除stash 记录
drop stash_id #删除指定的某条记录，不跟参数就是删除最近的
git stash clear #清空所有暂存区的记录
4.7merge & rebase合并分支
这两个都可以合并分支。
git checkout master #切换分支master
git merge featureA #合并分支featureA
git rebase featureA #合并分支featureA
区别你们可以理解成有两个书架，你需要把两个书架的书整理到一起去，
==merge== ，比较粗鲁暴力，就直接腾出一块地方把另一个书架的书全部放进去，虽然暴力，但是这种做法你可以知道哪些书是来自另一个书架的；
==rebase== ，他会把两个书架的书先进行比较，按照购书的时间来给他重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来很有逻辑，但是你很难清晰的知道哪些书来自哪个书架的。
4.8 解决冲突（以后再写）
5.Git 分支管理
5.1 常用分支命令
git branch develop #新建分支
git checkout -b develop #新建并自动切换分支
git push origin develop #把develop 分支推送到远程仓库
git branch #查看本地分支列表
git branch -r #查看远程分支列表
git branch -d develop #删除本地分支
git branch -D develop #强制删除
git push origin :develop #删除远程分支
git checkout -b develop origin/develop#把远程的 develop 分支迁到本地并切换（本地没有deelop）
执行上述命令的新建分支，是基于当前所在分支的基础上进行的，新建的分支和原来分支一模一样。
5.2 分支管理流程 Git Flow
Git Flow 是一种比较成熟的分支管理流程，一张图能清晰的描述他整个的工作流程：
一般开发来说，大部分情况下都会拥有两个分支 master 和 develop，他们的职责分别是：
==master==：永远处在即将发布(production-ready)状态
==develop==：最新的开发状态
master、develop 分支大部分情况下都会保持一致，只有在上线前的测试阶段，develop 比 master 的代码要多，一旦测试没问题，==准备发布时候会将 develop 合并到master 上。==
发布后继续进行下一版本的功能开发，开发中间可能遇到问题：
1.需要紧急修复 bug，
2.一个功能开发完成之后突然需求变动了
所以 Git Flow 除了以上 master 和 develop两个主要分支以外，还提出了以下三个辅助分支：
==feature: 开发新功能==, 基于 develop, 完成后 merge 回 develop
==release 准备发布版本的分支==，用来修复 bug，基于 develop，完成后 merge 回develop 和 master
==hotfix: 修复 master 上的问题==，等不及 release 版本就必须马上上线。基于 master, 完成后merge 回 master 和 develop
举例：1.基于 develop 分支新建个分支==做功能A==：
git branch feature/A #其实就是一个规范，规定了所有开发的功能分支都以 feature 为前缀。
2.遇到==紧急bug==需要修复。赶紧停下手头的工作，立刻切换到 master 分支，然后再此基础上新建一个分支：
git branch hotfix/B #紧急修复分支，修复完成之后直接合并到 develop 和 master ，然后发布
之后再切回我们的 feature/A 分支继续开发。
3.==最终测试==。开发完了，合并回 develop 分支，然后在 develop 分支测试环境。跟后端对接并且测试的差不多了，可以正式发布了，这时候再新建一个 release 分支：
git branch release/1.0
这个时候所有的 api、数据等都是正式环境，然后在这个分支上进行==最终测试==，发现 bug 直接进行修改，直到测试 ok 达到了发布的标准，最后把该分支合并到 develop 和 master 然后进行发布。
以上就是 Git Flow 的概念与大概流程，看起来很复杂，但是对于人数比较多的团队协作现实
开发中确实会遇到这么复杂的情况，是目前很流行的一套分支管理流程。
5.3 Git Flow实际应用
有人会问，每次都要各种操作，合并来合并去，有点麻烦，这点 Git Flow 早就想到了，并为此推出了一个 Git Flow 的工具，并且是开源的：Git Flow开源地址
这个工具帮我们省下了很多步骤：
git flow feature start A #基于develop分支新建分支feature A
git flow feature finish A #合并本分支到 develop 分支
如果是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支
Git Flow具体安装与用法有待补充
6.GitHub 开源项目参与
6.1 Github项目页面介绍
有人疑问，我自己目前还没有能力开源一个项目，但是想一起参与到别的开源项目中，该怎么操作呢？那么今天，就来给大家一起介绍下 GitHub 上的一些常见的操作。
以 Square 公司开源的 Retrofit 为例来介绍，打开链接：https://github.com/square/retrofit然后看到如下的项目主页：
第一部分包括 Watch、Star、Fork，之前介绍过。第二部分，分别包括 Code、Issues、Pull requests、Projects、Wiki、Pulse、Graphs。后面我们会一个个解释下（6.2和6.3）。
6.2 Pull requests：提交PR参与开源项目
GitHub 的最大魅力在于人人都可参与开发或者完善开源项目，通过 Pull requests 来完成，简称 PR。下面来详细演示如何发起 PR：
==第一步，Fork开源项目==
登录你的 GitHub 账号，然后找到你想发起 PR 的项目，这里以datawhale开源项目《基于transformers的自然语言处理(NLP)入门》 为例，点击右上角的 Fork 按钮，然后该项目就出现在了你自己账号的 Repository 里，点开后显示：
可以看到左上角有一行小字：forked from datawhalechina/learn-nlp-with-transformers。除此之外，项目代码跟原项目一模一样，对于原项目来说，相当于别人新建了一个分支而已。
==第二步，clone远程项目到本地==
修改的 bug 也好，想要新增的功能也好，总之把自己做的代码改动开发完，保存好。接着，把自己做的代码改动 push 到 你自己的 GitHub 上去。
==第三步，提交PR==
点自己主页 Fork 过来的项目主页，点击上方Pull requests 切换页面，点击右上角New pull request 按钮，会到如下页面：
这个页面会==自动比较该项目与原有项目的不同之处==。最顶部声明了是datawhalechina/learn-nlp-with-transformers 项目的 main 分支与 fork 过来的 datawhalechina/learn-nlp-with-transformers项目 mian 分支所做的比较。下面英文These branches can be automatically merged表示这两个分支可以自动合并。
写好标题和描述，然后我们点击中间的==Create pull request==按钮，至此我们就成功给该项目提交了一个 PR。
然后就等着项目原作者 review 你的代码，并且决定会不会接受你的 PR，如果接受，那么恭喜你，你已经是该项目的贡献者之一了。
6.3 其它功能简介
==Code：代码文件==。项目的根目录里会添加一个介绍性的 README.md 文件。
==Issues：项目问题或 bug==。并不是说 Issues 越少越好，Issues 被解决的越多说明该项目越受作者重视。 有close（解决）和open （待解决）两种状态。
同时，大家有问题的时候都可以提 Issue，可以通过点击右上角的New Issue 来新建 。
==Projects==
这个这个功能就是方便你把一些 Issues、Pull requests进行分类。
==Wiki==
一般来说，我们项目的主页有 README.me 基本就够了，但是有些时候我们项目的一些用法很复杂，需要有详细的使用说明文档给开源项目的使用者，这个时候就用到了 Wiki。使用起来也很简单，直接点击右上角 New Page ，然后使用 markdown 语法即可进行编写。
==insights==
可以理解成该项目的活跃汇总。包括近期该仓库创建了多少个 Pull Request 或 Issue，有多少人参与了这个仓库的开发等，都可以在这里一目了然。根据这个页面，用户可以判断该项目受关注程度以及项目作者是否还在积极参与解决这些问题等。
Settings
如果一个项目是自己的，那么你会发现会多一个菜单 Settings，这里包括了你对整个项目的设置信息，比如对项目重命名，比如删除该项目，比如关闭项目的 Wiki 和 Issues 功能等，不过大部分情况下我们都不需要对这些设置做更改。感兴趣的，可以自行看下这里的设置有哪些功能。
以上就就是一个 GitHub 项目的所有操作，相信大家看完之后对 GitHub 上常用的操作都熟悉了。
7.如何找到优秀开源项目
有同学问了，GitHub 我大概了解了，Git 也差不多会使用了，但是 还是搞不清 GitHub 如何帮助我的工作，怎么提升我的工作效率？
问到点子上了，GitHub 其中一个最重要的作用就是发现全世界最优秀的开源项目，你没事的时候刷刷微博、知乎，人家没事的时候刷刷 GitHub ，看看最近有哪些流行的项目，久而久之，这差距就越来越大，那么==如何发现优秀的开源项目呢？==这篇文章我就来给大家介绍下。
7.1 关注一些活跃的大牛
GitHub 主页有一个类似微博的时间线功能，所有你关注的人的动作，比如 star、fork 了某个项目都会出现在你的时间线上，这种方式适合我这种比较懒的人，不用主动去找项目，而这种基本是我每天获取信息的一个很重要的方式。不知道关注哪些人怎么办？找到一个大牛的账号，看看他都关注了谁。
7.2 Trending热度
点击主页最上方的Explore 菜单跳到发现页面：
紧接着点击 Trending 按钮
Trending 直译过来就是趋势的意思，就是说这个页面你可以看到最近一些热门的开源项目，这个页面可以算是很多人主动获取一些开源项目最好的途径，可以选择「当天热门」、「一周之内热门」和「一月之内热门」来查看，并且还可以分语言类来查看，比如你想查看最近热门的 Android 项目，那么右边就可以选择 Python 语言。
这样页面推荐大家每隔几天就去看下，主动发掘一些优秀的开源项目。
7.3 Search优秀项目
除了 Trending ，还有一种最主动的获取开源项目的方式，那就是 GitHub 的 Search 功能。
举个例子，你是做AI 的，接触 GitHub 没多久，那么第一件事就应该==输入Python 关键字进行搜索==，然后右上角选择按照 star 来排序，结果如下图：
可以看到按照 star 数，排名靠前基本是一些比较火的项目，一定是很有用，才会这么火。值
得一提的是左侧依然可以选择语言进行过滤。
==而对于实际项目中用到一些库==，基本上都会第一时间去 GitHub 搜索下有没有类似的库，比如项目中想采用一个网络库，那么不妨输入 android http 关键字进行搜索，因为我只想找到关于Android 的项目，所以搜索的时候都会加上 android 关键字，按照 star 数进行排序，结果如下：
除此之外，GitHub 的 Search 还有一些小技巧，比如你想搜索的结果中 star 数大于1000的，那么可以在搜索栏填入：
android http stars:>1000
总结
GitHub 上优秀开源项目真的是一大堆，就不一一推荐了，授人以鱼不如授人以渔，请大家自行主动发掘自己需要的开源项目吧，不管是应用在实际项目上，还是对源码的学习，都是提升自己工作效率与技能的很重要的一个渠道，总有一天，你会突然意识到，原来不知不觉你已经走了这么远！
Tips：常见报错
在git clone 克隆项目时报错，这是服务器的SSL证书没有经过第三方机构的签署，所以报错。
解决办法：
git config —global http.sslVerify “false”
8.HuggingFace/Transformers
预训练模型参数不断变大,来源Huggingface（这网页干啥的我也没看，不清楚，后面补）
教程使用的transformer代码库在HuggingFace/Transformers，也就是HuggingFace写的，是现在最流行的版本。HuggingFace主页项目还有tokenizers、datasets等。（第四章会用这里的数据集）
还有个
Transformer项目主页第二段也写了，Transformers包提供各种预训练模型，在model hub可以找到。比如4.1中开头写到model_checkpoint = “distilbert-base-uncased”。故4.1使用的模型是distilbert-base-uncased。
下图可以看出，transformer项目里的模型checkpoint有67种，model hub里由用户和组织上传的模型成百上千种。
教程4.1最后写了，自己写的模型可以上传模型到 Model Hub。具体上传办法点这里。之后就可以像教程4.1里一样，直接用模型名字就能使用自己上传的模型啦。
在Model Hub搜索 bert-base-chinese 结果如下：
第一各模型名字就是bert-base-chinese，应该是官方的模型（作者的） ，第二个模型前面有ckiplab/表示这个模型是ckiplab写的。即个人上传的模型。
9.colab使用技巧
colab训练后保存的模型，并没有和自己的google drive云盘绑定，实际上只是保存在了colab的当前内存中，等你下次刷新就没了。而colab上训练好的模型保存到云盘有两种方法：
- 挂载模型后切换到my drive目录，保存模型==保存模型==
#connect to self drive
from google.colab import drive
drive.mount('/content/drive')
import os
os.chdir('/content/drive/My Drive')
import torch |