0.1. 规范 0.1.1. Header 0.1.2. Body 0.1.3. Footer 0.1.4. commit.template 0.2. Messages 0.2.1. 使用祈使句 0.2.2. 首字母大写 0.2.3. 尽量做到只看注释便可明白而无需查看变更内容 0.2.4. 使用信息本身来解释“原因”、“目的”、“手段”和其他的细节 0.2.5. 避免使用无上下文的信息 0.2.6. 限制每行字数 0.2.7. 保持语言的一致性 0.1. 规范 参考 Angular 团队的 commit 规范。 <type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer> 分别对应 Commit message 的三个部分： Header ， Body 和 Footer 。 0.1.1. Header Header 部分只有一行，包括三个字段： type （必需）、 scope （可选）和 subject （必需）。 type : 用于说明 commit 的类型。一般有以下几种: feat: 新增feature fix: 修复bug docs: 仅仅修改了文档，如readme.md style: 仅仅是对格式进行修改，如逗号、缩进、空格等。不改变代码逻辑 refactor: 代码重构，没有新增功能或修复bug perf: 优化相关，如提升性能、用户体验等 test: 测试用例，包括单元测试、集成测试 chore: 改变构建流程、或者增加依赖库、工具等 revert: 版本回滚 scope : 用于说明 commit 影响的范围，比如: views, component, utils, test... subject : commit 目的的简短描述 0.1.2. Body 对本次 commit 修改内容的具体描述, 可以分为多行。如下所示: # body: 72-character wrapped. This should answer: # * Why was this change necessary? # * How does it address the problem? # * Are there any side effects? # initial commit 0.1.3. Footer 一些备注, 通常是 BREAKING CHANGE (当前代码与上一个版本不兼容) 或修复的 bug(关闭 Issue) 的链接。 0.1.4. commit.template # 这个命令只能设置当前分支的提交模板 git config commit.template [模板文件名] # 这个命令能设置全局的提交模板，注意global前面是两杠 git config --global commit.template [模板文件名] 新建 .gitmessage.txt (模板文件) 内容可以如下: # headr: <type>(<scope>): <subject> # - type: feat, fix, docs, style, refactor, test, chore # - scope: can be empty # - subject: start with verb (such as 'change'), 50-character line # # body: 72-character wrapped. This should answer: # * Why was this change necessary? # * How does it address the problem? # * Are there any side effects? # # footer: # - Include a link to the issue. # - BREAKING CHANGE # 0.2. Messages 原仓库地址。 0.2.1. 使用祈使句 # good Use InventoryBackendPool to retrieve inventory backend // 用 InventoryBackendPool 获取库存 # bad Used InventoryBackendPool to retrieve inventory backend // InventoryBackendPool 被用于获取库存 commit 信息描述的是引用的变更部分实际上做了什么，它的效果，而不是因此被做了什么。 0.2.2. 首字母大写 # Good Add `use` method to Credit model # Bad add `use` method to Credit model 首字母大写的原因是遵守英文句子开头使用大写字母的语法规则。 0.2.3. 尽量做到只看注释便可明白而无需查看变更内容 # Good Add `use` method to Credit model // 为 Credit 模块添加 `use` 方法 # Bad Add `use` method // 添加 `use` 方法 --- # Good Increase left padding between textbox and layout frame // 在 textbox 和 layout frame 之间添加向左对齐 # Bad Adjust css // 就改了下 css 它在许多场景中（例如多次 commit、多个更改和重构）非常有用，可以帮助审查人员理解提交者的想法。 0.2.4. 使用信息本身来解释“原因”、“目的”、“手段”和其他的细节 # Good Fix method name of InventoryBackend child classes Classes derived from InventoryBackend were not respecting the base class interface. It worked because the cart was calling the backend implementation incorrectly. # Good Serialize and deserialize credits to json in Cart Convert the Credit instances to dict for two main reasons: - Pickle relies on file path for classes and we do not want to break up everything if a refactor is needed - Dict and built-in types are pickleable by default # Good Add `use` method to Credit Change from namedtuple to class because we need to setup a new attribute (in_use_amount) with a new value 信息的主题和正文之间用空行隔开。其他空行被视为信息正文的一部分。 像“-”、“*”和“\”这样的字符可以提高可读性。 0.2.5. 避免使用无上下文的信息 # Bad Fix this Fix stuff It should work now Change stuff Adjust css 0.2.6. 限制每行字数 Pro Git Book建议： 主题最多使用50个字符， 正文最多使用72个字符。 0.2.7. 保持语言的一致性 对于项目所有者而言：选择一种语言并使用该语言编写所有的 commit 信息。理想情况下，它应与代码注释、默认翻译区域（用于本地化项目）等相匹配。 对于贡献者而言：使用与现有 commit 历史相同的语言编写 commit 信息。 # Good ababab Add `use` method to Credit model efefef Use InventoryBackendPool to retrieve inventory backend bebebe Fix method name of InventoryBackend child classes # Good (Portuguese example) ababab Adiciona o método `use` ao model Credit efefef Usa o InventoryBackendPool para recuperar o backend de estoque bebebe Corrige nome de método na classe InventoryBackend # Bad (mixes English and Portuguese) ababab Usa o InventoryBackendPool para recuperar o backend de estoque efefef Add `use` method to Credit model cdcdcd Agora vai
版本控制演变过程 VCS出现之前 用目录拷区别不同版本 公共文件容易被覆盖 成员沟通成本很高，代码集成效率低下 集中式VCS/SVN 有集中的版本管理服务器 具备文件版本管理和分支管理能力 集成效率有明显地提高 客户端必须时刻和服务器相连 分布式VCS/SVN 服务器和客户端都有完整的版本库 脱离服务端，客户端照样可以管理版本 查看历史和版本比较等多数操作，都不需要访问服务器，比集中式VCS更能提高版本管理效率 Git的特点 最优的存储能力 非凡的性能 开源 很容易做备份 支持离线操作 容易定制工作流程 注意 所有的版本控制系统，只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。 而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。 Microsoft的Word格式是二进制格式，版本控制系统是没法跟踪Word文件的改动的，如果要真正使用版本控制系统，就要以纯文本方式编写文件。 因为文本是有编码的，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。 安装git Linux sudo apt-get install git //Debain or Ubunt sudo yum install git //Redhat or Centos 老版本可能叫 git-core。 Mac OS X 安装homebrew，然后通过homebrew安装Git，具体方法请参考homebrew文档。 直接从AppStore安装Xcode，Xcode集成了Git，不过默认没有安装，你需要运行Xcode，选择菜单“Xcode”->“Preferences”，在弹出窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装了。 Windows 在Windows上使用Git，可以从Git官网直接下载安装程序，然后按默认选项安装即可。 安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！ Git最小化配置 配置user.name和user.email git config --global user.name 'your_name' git config --global user.email 'your_email' Git的三个作用域 优先级： local > global > system 缺省等同于local git config --local #local只对仓库有效 git config --global #global对登录用户所有仓库有效 git config --system #system对系统的所有用户有效 显示config的配置，加--list git config --list --local git config --list --global git config --list --system 设置，缺省等同于local git config --local git config --global git config --system 清除设置 git config --unset --local user.name git config --unset --global user.name git config --unset --system user.name 创建Git仓库 两种场景 把已有的项目代码纳入到Git管理 cd <项目代码所在文件夹> git init 新建的项目直接使用Git管理 cd <某个文件夹> git init project_name #会在当前路径下创建和项目名称相同的文件夹 cd project_name Git暂存区 git add . # 将当前路径下所有的文件都添加到暂存区中 git add <file> # 将<file>t添加到暂存区中 git add -u # 将已经被git追踪的文件进行更新 git reset -head # 重置HEAD、索引和工作区 git mv a b # 将被git追踪的文件a重命名为b并添加到暂存区中 Git版本历史 git log oneline # 查看简洁的历史 git log -n<number> #显示最近的n次日志 git log --all # 查看全部日志 git log --graph # 显示为图片 查看本地分支 git branch -v Git图形界面 # 安装gitk工具 sudo apt-get install gitk # 在git仓库目录下打开工具 gitk .git目录 drwxr-xr-x branches/ -rw-r--r-- COMMIT_EDITMSG -rw-r--r-- config # 本地仓库(local)相关配置 -rw-r--r-- description -rw-rw-r-- FETCH_HEAD -rw-rw-r-- gitk.cache -rw-rw-r-- HEAD # 指向仓库当前工作的分支 drwxr-xr-x hooks/ -rw-rw-r-- index drwxr-xr-x info/ drwxr-xr-x logs/ drwxr-xr-x objects/ #文件夹中的子文件夹都是以哈希值的前两位字符命名每个object由40位字符组成，前两位字符用来当文件夹，后38位做文件 drwxr-xr-x refs/headers # 分支 drwxr-xr-x refs/tags # 里程碑git cat-file # 命令 显示版本库对象的内容、类型及大小信息 git cat-file -t b44dd71d62a5a8ed3 # 显示版本库对象的类型 git cat-file -s b44dd71d62a5a8ed3 # 显示版本库对象的大小 git cat-file -p b44dd71d62a5a8ed3 # 显示版本库对象的内容 git中的对象： commit：一次提交生成一个tree tag：里程碑 tree：保存对应commit时间点，仓库中文件与目录的结构以及其中的内容 blob：表示一个文件，与文件名无关与文件内容有关 通常，blob表示一个文件，tree表示一个文件夹。 在Git中，文件内容相同的文件就是唯一的一个blob。 没有文件也就是没有blob对象的目录是不会被git管理的，因为git要对文件进行版本管理，所以没有必要对空目录生成对象。基于这一点，假设readme文件的全路径是这样：[仓库根目录]/doc/readme。那么tree的数量与全路径中“/”的数量一致。 即，有几层文件夹，就有几个tree。 一个commit对应一个tree，这个是root节点。 分离头指针(HEAD) git checkout <commit ID> 可用于在对应commit下进行实验性尝试，尝试完成后直接切换回原分支即可。 Git认为没有与分支或tag绑定的commit都应该丢弃。 HEAD与branch HEAD可以指向分支的最后一次commit HEAD也可以指向某一个具体的commit HEAD永远指向commit。 git diff <commit ID> <commit ID> # 比较两次commit的差异 git diff HEAD HEAD^1 # 比较HEAD与HEAD前的一个commit # HEAD^^ == HEAD~2
删除不需要的分支 git branch -d/-D <分支名> 修改最新commit的message git commit -amend # :wq! 保存退出 修改旧commit的message git rebase -i <commitID的parent> # 在交互界面中进行如下操作 # 步骤一，选择要进行的操作 #:wq! # 步骤二，进行操作 # :wq! 已经集成到团队分支中，不可进行这样的操作。 合并多个连续的commit git rebase -i <commitID的parent> # 在交互界面进行如下操作 # 步骤一，选择一个pick和多个squash # : wq! # 步骤二，新增一条commit message # : wq! 合并多个间隔的commit git rebase -i <commitID的parent> # 如果某个commit没有父commit，那么就选择该commit后，手动将它添加到交互界面中 # 将需要合并的commit剪切到一起，需要被合并的修改为squash，不变的依然是pick # :wq! git rebase --continue # 修改commit信息 # :wq! 比较暂存区和HEAD所含文件的差异 git diff --cached 比较工作区和暂存区所含文件的差异 git diff # 比较工作区和暂存区的所有文件 git diff -- <file> # 比较该文件在工作区和暂存区的差别 将暂存区恢复成与HEAD一致 git reset HEAD #针对暂存区全部文件 git rest HEAD -- <file1> <file2># 针对暂存区中某个文件 将工作区文件恢复成与暂存区一致 git checkout # 针对工作区全部文件 git checkout -- <file> # 针对工作区某个文件 消除最近的几次提交 git reset --hard <commitID> # commitID之后的commit记录都会被删除 查看不同提交的指定文件的差异 git diff <branch1> <branch2> # 比较两个分支全部文件的不同 git diff <commitID1> <cimmitID2> git diff <branch1> <branch2> -- <file> # 比较两个分支中指定文件的不同 git diff <commitID1> <cimmitID2> -- <file> 正确删除文件的方法 git rm <file> 临时加塞紧急任务如何处理 git stash # 将当前工作区中文件存入临时堆栈中 git stash list # 查看临时堆栈中内容 git stash apply # 复制临时堆栈的内容到工作区 git stash pop <stash序号> # 提取临时堆栈的内容到工作区，默认为顶部内容 指定不需要Git管理的文件 .gitignore文件 空行不匹配任何文件，因此它可以作为可读性的分隔符。 以＃开头的行作为注释。对于以哈希开头的模式，在第一个哈希前面加一个反斜杠（“\”）。 除非使用反斜杠（“\”）引用尾随空格，否则将忽略尾随空格。 可选前缀“!”否定了这种模式;之前模式排除的任何匹配文件将再次包含在内。如果排除该文件的父目录，则无法重新包含文件。出于性能原因，Git不会列出排除的目录，因此无论在何处定义，所包含文件的任何模式都不起作用。在第一个“! ”前放一个反斜杠（“\”）对于以文字“！”开头的模式，例如“\！important！.txt”。 如果模式以斜杠结尾，则为了以下描述的目的将其删除，但它只会找到与目录的匹配项。换句话说，foo /将匹配目录foo和它下面的路径，但是不匹配常规文件或符号链接foo（这与pathpec在Git中的工作方式一致）。 如果模式不包含斜杠/，Git将其视为shell glob模式，并检查相对于.gitignore文件位置的路径名匹配（相对于工作树的顶层，如果不是来自.gitignore）文件）。 否则，Git将模式视为shell glob：“*”匹配除“/”，“？”之外的任何内容。匹配除“/”之外的任何一个字符，“[]”匹配所选范围中的一个字符。有关更详细的说明，请参阅fnmatch（3）和FNM_PATHNAME标志。 前导斜杠与路径名的开头匹配。例如，“/*.c”匹配“cat-file.c”但不匹配“mozilla-sha1 / sha1.c”。 与完整路径名匹配的两个连续星号（“**”）可能具有特殊含义： 前面的斜杠“”表示匹配所有目录。例如，“/foo”在任何地方匹配文件或目录“foo”，与模式“foo”相同。 “**/foo/bar”将文件或目录“bar”与直接位于“foo”目录下的任何位置匹配。 尾随“/”匹配内部的所有内容。例如，“abc/”匹配目录“abc”内的所有文件，相对于.gitignore文件的位置，具有无限深度。 斜杠后跟两个连续的星号，然后斜杠匹配零个或多个目录。例如，“a/**/b”匹配“a/b”，“a/x/b”，“a/x/y/b”等。 其他连续的星号被认为是常规星号，并且将根据先前的规则匹配。 将Git仓库备份 git clone --bare <协议及仓库地址> # 不带工作区的裸仓库 git remote -v # 查看远端仓库 git remote add <remove name> <协议及仓库地址> git push --set-upstream 常用传输协议 常用协议 语法格式 说明 本地协议1 /path/to/repo.git 哑协议 本地协议2 file:///path/to/repo.git 智能协议 http/https协议 http(s)://git-server.com:port/path/to/repo.git 平时接触到的都是智能协议 ssh协议 user@git-server.com:path/to/repogit 工作中最常用的智能协议 哑协议与智能协议 直观区别：哑协议传输进度不可见，智能协议可见 传输速度：智能协议比哑协议快
配置公私钥 创建SSH Key 在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key： ssh-keygen -t rsa -b 4096 -C "youremail@example.com" 在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对： id_rsa是私钥，不能泄露出去 id_rsa.pub是公钥，可以放心地告诉任何人 登陆GitHub 打开“Account settings”，“SSH Keys”页面 点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容 点“Add Key”，就应该看到已经添加的Key 为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。 当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。 把本地仓库同步到GitHub 在本地创建了一个Git仓库后，想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作。 登陆GitHub 在右上角找到“Create a new repo”按钮，创建一个新的仓库 在Repository name填入仓库的名字(如 my_repo)，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库 在GitHub上的这个my_repo仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。 根据GitHub的提示，在本地的my_repo仓库下运行命令： git remote add origin git@github.com:<your Github name>/my_repo.git # 根据github页面给的提示输入命令即可 添加后，远程库的名字就是origin（这是Git默认的叫法，也可以改成别的)，但是origin这个名字一看就知道是远程库。 最后，就可以把本地库的所有内容推送到远程库上： git push -u origin master 把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。 由于远程库是空的，第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送到远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。 推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样。 从现在起，只要本地作了提交，就可以通过命令： git push origin master 把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！ 将本地和远程库集成 将远程库的变更拉取到本地 git fetch <remote name> <branch name> 将拉取的远程库和本地库合并 git merge <remote name>/<branch name> # 将历史相关（父子关系的，即两个分支非fast forward）的分支 git merge --allow-unrelated-histories <remote name>/<branch name> # 将历史不相关的分支合并 # 修改merge message # :wq! 注意： git pull = git fetch + git merge 从远程库克隆 假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。 登陆GitHub，创建一个新的仓库，名字叫zero 勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件 远程库已经准备好了，下一步是用命令git clone克隆一个本地库： git clone git@github.com:<your github name>/zero.git #在页面的右上角可以直接复制该链接 进入本地的目录就可以看到初始化创建的README.md文件 如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。 GitHub给出的地址不止一个，还可以用 https://github.com/yourgithubname/zero.git 这样的地址。 实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。 使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
不同人修改不用文件 # 用户一的操作 git branch -av # 查看仓库中全部的分支（包括本地和远程） git checkout -b feature/add_git_commands origin/feature/add_git_commands # 基于远程仓库的分支origin创建本地分支，并切换到新建的分支上 git branch -v # 只查看本地分支 git push <远程仓库名称，默认是origin>/<分支的名称> # 将当前分支推送到远程仓库中对应的分支 # 因为创建时有本地分支和远程仓库中的分支有关联关系，上述命令可以缺省远程仓库中分支的选择 # 用户二的操作 git fetch <远程仓库的名字，默认为origin> # 将远程仓库中分支的变更都同步到本地仓库 git merge <远程仓库名>/<远程仓库分支名> # 将本地当前分支与远程仓库中的指定分支合并 # 填写merge信息，然后 :wq! git push 不同人修改同文件不同区域 开发之前先同步远程仓库 # 操作方式一 git pull # 同步远程仓库中的代码，并且与本地分支进行合并 # 操作方式二 git fetch # 将本地仓库中远程分支与远程仓库中对应的分支进行同步 git merge <远程仓库名>/<远程仓库分支名> # 将本地当前分支与本地仓库的远程分支合并 # 填写merge信息，然后 :wq! 不同人修改同文件同区域 <<<<< # 这里是本地的文件内容 ==== # 这里是远程仓库的文件内容 >>>>> # 直接在文件上进行修改，将需要的内容保留，不需要的内容删除 git commit # 提交解决的冲突 git push # 将解决后的commit推送到远程仓库中 git merge --abort # 放弃解决的冲突 同时变更文件名和文件内容 git存放blob文件时是以文件内容来区分的，并不以文件名来区分；此处的变更文件名操作和变更文件内容的操作能够自动被git处理，原因就在于blob文件并没有发生修改的冲突。 如果既变更了文件名又修改了文件，同时另一个人也修改了该文件的同一位置的内容，就会被git识别为冲突，而不能自动进行处理了。 git mv file1 file2 git pull # git能够智能感知到文件名的变化，因为是git是基于文件内容区分的 同时修改同一文件名 git会报告冲突，自行判断要使用哪个文件名，然后在提交。 git add <需要的filename> git rm <不需要的filename> 禁止向集成分支执行push -f操作 git push -f # 强制更新 禁止向集成分支执行变更历史操作 公共分支禁止rebase。
GitHub为什么这么火 共享和搜索开源项目 让Git更容易使用 使协作和编写软件更容易 GitHub的核心功能 code review project management integrarion team management social coding document code hosting 快速搜索感兴趣的开源项目 搜索技巧 in关键字 xxx in:name 项目名包含xxx的 xxx in:description 项目描述包含xxx的 xxx in:readme 项目的readme文件中包含xxx的 xxx in:name,desciption来组合使用 star或fork数查找项目 通过通配符 > < = 即可，区间范围内可通过 num1..num2 xxx stars:>600 xxx forks:>500 xxx forks:100..200 stars:200..300 awesome xxx 分享项目中某一行代码 只需要在具体的网址后面拼接#Lxx(xx为行数)，浏览器访问 发现高亮显示了 当然也可以段落进行高亮显示#Lxx-xx 项目内搜索 打开你想要搜索的项目，然后按一下‘T’键。会跳转至一个新的网页，然后输入想要搜索的文件名 搜索某地区大佬 location：shanghai language:java 开源项目怎样保证代码质量 GItHub使用PR进管理。 为何需要组织类型的仓库 仓库 成员 团队
命令 描述 git add <filename> 添加修改后的文件 git commit -m "describe" 提交修改 git status 查看仓库当前状态 git diff 查看文件的区别 git log 查看历史版本 git reset --hard 回退到上一个版本 git reflog 记录每一次执行的命令 git checkout -- <filename> 把工作区的修改撤掉（让文件回到最近一次git add或git commit之前那一刻的状态） git reset HEAD <filename> 把暂存区的修改撤销掉 （HEAD 表示最新版 HEAD^b表示上一版本，HEAD为一个指针） git rm <filename> 删除文件 git push origin master 把本地内容推送到远程（第一次推送分支时，用-u参数） git clone 克隆一个远程仓库到本地（Git支持多种协议） git branch 查看当前仓库中的所有分支（当前分支用*标记出） git branch <branchname> 创建分支 git checkout <branchname> 切换到分支 git merge <branchname> 合并指定分支到当前分支 git log --graph 查看分支合并图 git stash 保存当前工作现场（暂存区） git stash list 显示保存的所有工作现场 git stash pop 恢复之前保存的工作现场并把保存在stash列表中的内容删除 git stash apply 恢复之前保存的工作现场保留保存在stash列表中的内容 git stash drop 把保存在stash列表中的内容删除 git remote 查看远程仓库信息 git push origin <分支名称> 把该分支上的所有本地文件推送到远程仓库 git clone 克隆一个远程仓库到本地 git pull 从远程拉取最新的分支 git tag <name><commit ID> 打一个新标签或者查看所有标签 git show <tagname> 查看tag的说明文字 git push origin <tagname> 推送某个标签到远程 git push origin ：refs/tags/<tagname> 删除远程的某个标签