一篇博客解决git操作
git教程：
是一种版本控制器，是一个记录每一次版本记录一个或若干个文件内容的变化，以便将来查询特定版本修订情况的系统。
可以通过它恢复之前的样子，可以一键还原
可以通过比较文件的变化细节，可以找到谁修改了这段代码，这是一种分布式的版本控制器，操作要比SVN复杂一点。
集中式的管理的优缺点：（代码存储在单一的服务器上便于项目的管理，客户端只提取最新版本的快照）
优点：
集中化的管理
方便存储
缺点：
中央出现故障，没有保障。（SVN服务器宕机就不能工作了；需要手动保存代码，如果恢复之前版本会出现丢失数据，或者时间一长就无法找到完整的之前代码的对照）；
如果中央存储出现问题，那么版本无法恢复管理。
分支操作麻烦需要到服务器端拉分支再从客户端接入
分布式的管理的优缺点
（可以提取不只是最新版本的快照，而是存储仓库完整的镜像。可以通过其他本地的服务器（可以都是客户端）完整的保存下来）（可以没有网络的情况下开发，因为本地有历史记录）
分布式的管理存放的不是项目版本与版本之间的差异，它存的是索引（所需的磁盘空间较小很多时候都是存索引，有时候会存压缩文件）所以每个客户端都可以放下整个项目的历史记录；
列如：有100次存储那么SVN需要一步一步的回滚，GIT需要存储所有的索引，可以一步回到对应版本
SVN每次存储的内容会小一点（内存要求要小一些），但恢复历史版本会麻烦一点
GIT每次存储的都是这个项目完整的快照，（内存要求要大一点，但做过压缩内存不会大很多），但是恢复历史版本要快一点（可以加内存，但是很难加CPU所以选择GIT更好）
使用GITHUB客户端进行GIT操作；
可以客户端自己创建分支更加便捷
GIT简史：
linux开发者linux torvalds参与开发
（linux内核维护工作很多都花在了提交补丁和保存归档的繁琐）
其实很多大型项目都借助了操作系统的模式，GIT可以采用分布式管理超大型项目，有点类似于LINUX同时支持多用户进行操作。
下载地址：
https://git-scm.com/download/win
https://git-scm.com/download/mac
git初始化过程（第一次使用）需要配置一下工作环境：
Git config --global user.name”名字”
Git config --global user.email [email protected](邮箱)
这里的邮箱代表在git上提交版本的时候上面的邮箱，如果出现代码出现错误，可以通过邮箱提醒编写者
Git config --list
查看可以配置的信息，可以通过提示进行配置
--global当前用户提交
--system当前系统提交
不填 当前系统提交
git教程主要内容：
区域&对象
区域：
工作区、暂存区、版本区
对象：
git对象、树对象、提交对象
工作区：在工作区中新建文件、修改文件等等，（沙箱环境、临时生成的环境）
暂存区：暂时存放文件的地方（并不是所有的文件都需要创建一个版本）
版本区：最终版本
工作区提交到暂存区，暂存区达到一定程度，提交到版本区
git对象：
初始化对象：到工作区文件夹中使用gitbash here创建了一个隐藏的git文件夹，这个就是git仓库，里面就是版本库，在这个工作区文件中的所有操作都会存放在这个文件夹中。
Git init：初始化对象命令
里面包含多个文件夹表示不同的含义：
hooks目录包含客户端或服务端的钩子脚本（相当于一钟回调函数，符合规范提交不符合则不能提交（工作区向缓存区提交的钩子，缓存区向版本库提交的钩子））
Info：表示git不需要管理的文件
Logs：使用git产生的日志信息
Objects:目录存储所有的数据内容
Refs:存放提交对象（分支有关）
config配置文件（user 和email存储的文件）
Description:对仓库的描述信息
HEAD表示当前被检出的分支
index文件保存的暂存区
inux基本命令：
clear清除屏幕
Echo “testcommend” > test.txt创建文件
Ll:将当前目录下的子文件&子目录平铺到控制台
Find：将对应目录的子孙目录输出到工作台
Find -type f：查看对应文件类型的文件
Rm 删除文件
Mv 原文件 更改之后的名字 更改文件名
Cat 文件查看文件内容
Vi 修改文件内容set nu 设置行号
底层命令（弄清原理就行了，不需要特别记忆）
Git对象：
Key:val(Key:val生成的hash是blob类型的键值对hash-object)
git的核心部分是一个简单的键值对数据库，你可以向该数据库插入任意类型的内容，它会返回一个键值，通过该键值可以在任何时刻再次检索该内容
向数据库中写入内容 并返回对应键值：
Echo “test content” |git hash-object -w --stdin（可替换成文件路径）
-w选项是指hash-object命令存储数据对象，若不指定此选项则该命令是返回对应的键值
--stbin（标准输入standar input）选项则指示该命令从标准库读取内容；若不指定则默认返回指定路径
（数据库的内容对应一个键值hash（唯一一个）头两个字符表示存储的目录（objects下的子目录）通过cat 查看会发现这里面的存储的内容被压缩了）
查看原内容：git cat-file -p hash值(git存取时生成出来的hash键)（查看压缩之后的内容）
-p自动指示命令中自动判断内容的类型，并为我们现实格式友好的内容
（换成-t可以查看git对象的类型-------blob类型）
（lf是Windows的换行 crlf是Linux的换行）
编写一个文件
Echo “hello a1” > hello.txt
Git hash-object -w hello.txt
生成第一个键值对
Echo “hello a2” >> hello.txt
Git hash-object -w hello.txt
生成第二个键值对
第一个和第二个之间会有重复内容，但是内容都经过压缩
Git cat-file -p hello.txt的hash键(第二个的hash键)
Hello a1hello a2
以上是对本地数据库进行管理不涉及缓存区
记录的版本不是文件的更新的版本，而是整个更新项目的版本
而且在git中文件名并没有被保存 我们仅保存了文件的内容
解决方案：树对象
树对象：
树对象，它能解决文件名保存的问题，也允许我们将多个文件名组织到一起，git以一种类似于unix文件系统的方式存储内容。所有内容均以树对象和数据对象（GIT对象）存储，其中树对象对应了Unix中的目录项，数据对象（git对象）则大致对应文件内容。一个树对象包含了一条或多条记录（每条记录含有一个指向git对象或者子树对象的sha-1指针。以及相应的模式，类型，文件名信息）。一个树对象也可以包含另一个树对象。
查看树对象：
Git cat-file -p master^（tree）（或者树对象的hash）
Master^(tree)表示master分支上更新的提交所指向的树对象
构建树对象：
我们可以通过update-index，write-tree，read-tree等命令来构建树对象并塞入到暂存区。
操作：
利用update-index命令将test.txt文件的首个版本创建一个暂存区，并通过write-tree命令生成树对象
git update-index --add --cacheinfo 100644 文件hash 文件全名
只是在暂存区中放置，而不是
Git write-tree
生成快照放到版本库中去，它实际上是一个树对象（可以延迟执行，攒数据，不会将暂存区中的内容清空）
文件模式：100644普通文件100755可执行文件120000符号链接
--add选项：
因为此前该文件并不在暂存区中 首次需要--add
--cacheinfo选项：
因为将要添加的文件位于git数据库中而不是位于当前目录下 所有需要cacheinfo
查看树对象 暂存区：git ls-files -s
git对象代表文件的一次次版本
树对象表示项目的一次次版本
更新第二个版本：test.txt（它会在缓存区中将文件内容替换如 末尾的文件名test.txt覆盖暂存区中的test.txt）
Echo “test.txt v2” >> test.txt
Git hash-object -w ./test.txt
Git update-index --cacheinfo test.txt的hash键 test.txt（不是第一次可以省略--add ）
Git write-tree（生成树对象，第二个版本）
二步跳跃直接生成tree对象（隐含生成git对象）
Echo “new.txt v1” > new.txt
Git update-index --add new.txt 直接生成tree在暂存区
在内存中：
第一个版本的树对象对应的是test.txt第一个版本
第二个版本的树对象对应的是test.txt第二个版本
（由于每个版本都是将暂存区中的内容存取到版本区，每一个树对象可以包含多个树对象也就是每一次使用write-tree都会生成一个版本对应着此时的暂存区的经过压缩的内容）
Git read-tree --prefix=bak 树对象的hash
会在暂存区生成一个指向这个树对象的bak
可以再次通过write-tree生成一个有包含指向版本树对象的对象
（但是一般不会包含指向版本区的树对象，而是更新之后的暂存区）
可以通过cat-file -p查看树对象所包含的内容
提交对象：（因为之前没有在对相关版本的描述，这个对象用来对每个版本有什么内容不同）
就是对树对象进行一次包裹，将git的配置信息和版本内容介绍等包含进去（user email）
（其实这就是帮我们理清版本之间的关系的对象）
通过创建commit-tree命令创建一个提交对象，为此需要指定一个树对象的sha-1值，以及提交的父提交对象，（如果有的话）没有需要在第一个暂存区创建一个
创建提交对象：echo “first-commit” |git commit-tree 树对象的hash（一般只需要前多少位的hash就可以唯一确定提交了）
查看提交对象：git cat-file -p 提交对象的hash
创建提交对象指定父提交对象：echo “second-commit” |git commit-tree 树对象的hash -p 父提交对象的hash
原理：
对于我们来说一个提交对象对应一个版本全部信息是链式的，而树对象是一次版本的快照
所以说git的每个版本存储的不是一个增量，而是快照
回滚的话只需要通过提交版本对应的hash
高层命令：
Git add 文件名/文件目录（./）
将包含的文件放到暂存区（但是它是先生成git对象在版本库，然后在放入版本库）
（所以说这个命令可以保证之前文件内容不丢失，然后满意为止生成树对象）
Git hash-object -w 文件名(可能多个)
Git update-index --add --cacheinfo hash 文件名（可能多个）
Git commit -m ‘注释内容’
将暂存区的内容做成一个树对象，然后创建一个提交对象包裹这个树对象，将注释内容和配置信息包含其中
（并不会清空缓存区）
Git write-tree
Git commit-tree 树对象hash （如果有父提交对象 -p 提交对象hash）
Git 高层命令：
Git init 初始化仓库
Git add ./ 添加到缓存区
Git commit -m 注释 提交版本
Git commit 直接打开vim编辑器输出更新的内容
Git status 查看文件的状态
Git diff 查看哪些修改还没有暂存
Git diff -cached/git diff -staged 查看哪些暂存还没有提交
Git commit -a 提交跟踪已经修改的工作文件
Git commit -a -m提交跟踪已经修改的工作文件并设置版本信息
Git log pretty=oneline查看历史记录,并输出到一行
Git log --oneline查看历史记录简化hash
Git rm 删除工作目录和暂存区（追踪）的文件
Git mv 重命名工作目录和暂存区（追踪）的文件
工作目录中：
文件可以随意的修改
纳入版本区或者暂存区中的文件不能随意的修改了
工作目录中的文件已经被保存入版本区或者暂存区中，那么该文件已跟踪，可以修改但是最好，没有则未跟踪
已跟踪的文件被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间之后，它们的状态可能是已提交，已修改，已暂存
所有其它文件为未跟踪文件
Git status 查看文件的状态（已跟踪或者未跟踪）
已提交的文件这里不会出现提示
当文件已修改使用的话可以看出文件已修改但没有暂存
暂存的文件：显示文件应该提交change to be committed
暂存已修改的文件：显示一个已暂存的状态和一个已修改为暂存的状态
查看已暂存和未暂存的更新
Git diff显示哪些更新没有暂存
Git diff -cached /git diff -staged显示哪些已经暂存可以提交
提交更新：git commit -m “message xx”
Git commit直接进入vim编辑器输入更新的内容，上面是简化
当保存退出之后自动提交信息（不能为空，空不能提交）
跳过暂存区的提交
Git commit -a 所有已跟踪的文件已修改直接提交到版本库中，其实就是省略了git add命令而已，过程还是一样的。（只有已经被初始化跟踪之后才能使用-a）
Git commit -a -m 注释
删除文件rm 文件名
Git add
Git commit
但是此时的工作区中的文件发生修改，如果提交到暂存区，只会将暂存区的内容没有这个文件，但是版本区还是会有这个文件。
这个操作还是一种修改操作。
Mv 文件名 新文件名
删除一个文件新增一个文件
使用git add ./更新
Git commit -m ‘更改内容’
查看历史记录：
Git log
q退出
Git log pretty=oneline
输出简化版的内容；
Git log --oneline简化hash之后输出！
删除重命名：
Git rm 从工作目录删除并且提交到暂存区只需要commit就行
Git mv 从工作目录重命名并且提交到暂存区再commit就行
一个团队使用一个git，而工作中是协同开发的，每个人都可以采用分支的方法开辟自己的工作空间（这个过程原本是工作人员自己保存一个备份内容，但是这样的话效率就比较低了）
分支基础：
分支就是一个活动的指针（列如master是一直指向最新提交对象的分支）
Git branch 分支名
创建了一个分支
Git checkout 分支名
切换到另一个分支，这个分支在更新的时候master不会更新，如果遇到麻烦回到master可以直接删除这个分支不会影响master分支，如果再次需要切换分支需要退回到master上切换
Git branch不加参数可以得到当前所有分支列表
Git branch -d 分支名 删除分支
Git branch -D 强行删除分支
Git branch -v 查看每个分支最后一次提交
Git log --oneline --decorate --graph --all查看所有分支的历史记录名称太长可以设置别名
Git config --global alias.配置别名 原来名字（使用的话git 别名即可）
(删除别名git config --global --unset alias.别名)
（删除所有别名 git config --global --remove-section alias 删除.gitconfig中的alias小节以及下面的内容）
Git branch name commitHash创建一个分支并将分支指向对应的提交对象
分支的本质是一个提交对象，head是一个指针，它默认指向master分支切换分支时其实就是head的指向不同。
每次提交时，head都会带着当前指向的分支一起往前移动
分支切换一定会改变工作目录中的文件，如果切换切换一个比较旧的分支，那么工作目录会恢复到该分支最后一次提交的样子。如果git不能干净利落地完成这个任务，它将禁止切换分支（每次提交分支之前，提交一下当前分支）
Git checkout -b test
相当于直接创建分支并切换过去，这个分支指向当前master的内容
切换分支动三个地方：HEAD,暂存区，工作目录
最佳实践方式：每次切换时保证当前分支是干净的（已提交办法）
如果没有干净的提交的话，切换时会将之前的分支的没有提交的文件都会移动到当前master分支，这样的话就会污染到master分支，即使之后切换分支这个文件已经提交，master文件依然会有这个文件，而且这个文件也被纳入到暂存区之中。这是非常严重的后果。当项目上线之后这些没有被排查出来的内容就会污染整个项目，造成很大的维护困难。
合并分支：
会计融合：当工作完了可以将这个分支与master分支融合（这时候可以让master完成更新）但是如果这个时候有其他分支没有合并的话，那么这些分支都是过期的（原本就是从之前的master拉下来的分支，更新的话master向前走了这个分支也就停留在之前的master上），所以更新要将当前的所有分支都合并到master上。
典型融合：
如果需要融合一个过期的内容，需要解决冲突问题，冲突的文件中，有标识冲突具体内容和分支名。需要手动删除不必要的冲突，通过git add ./解决冲突（如果没解决就Git add ./也是标识解决不满意自己重新修改在add） 最后提交更新版本
合并之后的分支已经输入master的内容了，就可以删除这个分支（没意义了）
分支模式：长期分支（head才是可变指针，不是master 其实master分支和普通分支是一样的只不过git init创建默认将它看做主分支通过它表示版本的更新，我们自己可以创建一个长期分支用来更新自己的工作内容，通过长期分支更新自己的内容）
项目实践：
正在完成当前工作，忽然接受到一个紧急通知，需要开发新功能完善内容，完善之后回到当前工作。
工作开展前：
首先有一个主分支和自己的工作分支
Git init
Git checkout -b test
创建自己的工作：
Echo “工作内容” > test.txt
接到紧急通知：需要创建新的分支
提交当前内容：
Git add ./
Git commit -m “紧急提交，修改其他文件”
//遇到紧急事件毫不犹豫提交就是了，等工作结束切换回来文件都在也不会有多余的内容
Git status查看当前目录是否干净
干净的话切换到master
Git checkout master
创建新分支完成紧急工作内容
Git checkout -b test2
工作之后提交
Git status
查看工作是否干净，不干净再次提交解决问题
Git checkout master
合并分支内容完成master版本的更新修复问题。
Git merge test2
Git checkout test
工作完提交内容
Git status
Git checkout master
Git merge test
解决冲突
Git add ./
Git commit
git存储：
当项目的一部分已经工作一段时间之后，所有东西都进入了混乱的状态，而这时你想要切换到另一个分支做点别的事情。问题是，你不想仅仅因为这一点时间将工作的内容提交。
Git stash命令
它会将未完成的修改保存到一个栈中，而你可以在任何时候重新应用这些改动git stash apply（不会删除栈顶元素只是应用它）
虽然已经提交了，但是这些内容不会保存在日志中。
Git stash list查看有什么存储
Git stash apply stash@(指定离栈顶多少的元素，不指定则默认是栈顶元素)
Git stash pop应用存储并且删除栈顶
Git stash drop移除存储可以是栈顶也可以是@stash（）最好不用多存储不然删除应用特别麻烦
后悔药：
三个级别：
工作区
如何撤回对工作目录中的修改
Git checkout --filename（相当于用暂存区的内容重置当前的指定文件）
暂存区
如何撤回自己的缓存
Git reset HEAD filename(hash)
版本区
如何撤回自己的提交(原理是将这次提交从日志中删除)
内容写错了
按理说可以直接使用同名文件替换再提交就行了。
注释写错了
如果文件写错了同时注释也写错了
需要先将文件提交到暂存区再来使用amend重新提交数据就能覆盖着一次操作。
Git commit --amend可以重新提交注释
Git reflog可以查看全部提交日志。（Git reflog）
Reset：
三部曲：
第一部：git reset --soft HEAD~(-mend类似，它移动的是整个head和master上所有的分支，往后退一步，再次提交不会覆盖上一次的内容而是重新产生了分支)
第二部：Git reset (--mixed) HEAD~(回到之前的提交对象的hash可以在reflog看能够看到)移动HEAD，修改暂存区内容
第三部：git reset --hard head~（动了HEAD暂存区和工作目录这个必要危险的命令，如果版本库中没有暂存区中没有，那么可能在切换时会丢掉工作目录中的未跟踪的文件）
git checkout 提交对象和git reset --hard 提交对象的区别
- checkout只动HEAD而--hard动HEAD和工作目录暂存区
- Checkout对工作目录是安全的，而--hard对工作目录是危险的它会覆盖原来的工作目录
Git reset (--mixed) HEAD~ （-mixed是默认选项）
好像reset没有这个命令了
路径reset：只有--mixed可以后接文件名
Git reset --mixed HEAD filename相当于只动暂存区，就是将暂存区的修改撤销（覆盖）回来Git reset filename
Checkout：
Git Checkout --filename只会动工作目录没有--hard中的前两步
Git checkout hash --filename跳过--hard第一步
数据恢复：
如果你丢失了一次提交（可能是因为你删除了一个分支，但实际上你还需要它或者你重置了一个分支，放弃了一次提交（--hard））该如何恢复？
可以通过git reflog查找当时的hash
或者通过logs文件夹中的HEAD打开找到hash
--hard回去或者回去创建一个分支指向这个hash重新开发然后融合回来
打tag：
Git给历史中的某一次提交打上标签，表示重要的一次更新，比较有代表性的是人们会使用这个功能来标记发布的结点。
Git tag查看所有的tag（git tag 一些通配符 查看相应的版本号 如-表示该版本之前的所有版本）
Git tag 版本号（表示将最新一次提交的对象打上tag）
Git tag 版本号 hash（表示给这个提交对象hash 打上tag）
Git tag -d 版本号 删除这个tag
Git show查看特定的标签
Git checkout版本号 检出标签（这样会提示你正处于detached HEAD状态）（检出的时候需要在当前状态创建一个分支git checkout -b 版本号就行了）
Git特点：
直接记录快照，而非差异比较
近乎所有操作都是本地执行
时刻保证数据的完整性
多数操作仅添加数据
文件的三种状态
Git工作流程：
Git status
Git add ./
Git commit -m
代码风格：
Eslint一般语言检测工具都是内嵌在编译器或者解释器上的，但是js没有，而js高级程序设计红宝书的作者创作的这个工具用来检测js出现的错误。
Eslint是通过node.js做出来的。Eslint的初衷是让程序员创建自己的检测规则，它被设计成可插入的，eslint的默认规则和其他插件没有什么区别，eslint中内置了一些规则共人们使用，当然可以自定义规则。
编程规范：
Lint（程序员编码格式工具的统一称呼列如Jlint、eslint）
使用eslint：node.js环境
Npm init -y
Npm i eslint --save-dev
打开package.json
配置在”scripts”:{
“test”:”echo \”Error: no test specified\” && exit 1”,
“lint”:”eslint ./src”,
“lint:create”:”estint --init”
}
Lint 配置目录（在这个eslint安装的目录中开始）配置名字使用npm run 配置名可执行操作如果是start就可以npm start
Lint:create启动初始化配置
Npm run lint:create
填写设置
使用 npm run lint检测代码是否符合规范
Git钩子（用来设置commit之前必须通过一个规范）
Husky 构建强约束如果不通过就不能提交。
必须先有仓库才能装husky，如果需要写在可以在package.json中奖husky删除使用npm i卸载
装入的仓库在eslint的module父目录中使用git init初始化仓库
安装husky使用npm install husky --save-dev即可
然后装入husky配置package.json中大括号中创建一个
“husky”:{
“hooks”:{
“pre commit”:”npm run lint”在提交强一定要通过这个脚本，注意json中是不能写注释的
}
}
用于模块在git中所以需要使用git排除这里的目录
在.git父目录创建一个.gitignore文件：
.gitignore创建这个文件配置忽略信息：
/node-modules（忽略这个目录）
提交的时候会自动的调用这个钩子程序
git复习：
Git分支：创建一个分支，本质上就是一个提交对象，所有分支都会有机会被HEAD所引用HEAD一个时刻只能指向一个分支，当我们有新的提交的时候，HEAD会携带当前分支往前移动。
Git branch 分支名 创建分支
Git checkout 分支名 切换分支
Git checkout -b 分支名 创建&切换分支
Git branch -d 分支名 删除分支
Git branch -D 分支名 强制删除分支
Git merge 分支 合并当前分支和其它分支
快进合并 不会产生冲突
典型合并 有可能产生冲突（改到同一个文件同一个代码）（当当前分支和这个分支不在一条线上。）
解决冲突之后 使用 add commit就可以了
Git branch查看branch列表
Git branch --merge 查看到合并到当前分支的分支，这个列表表示这些分支可以被删除。
Git branch --no-merge查看没有合并到当前分支的分支。
Git branch 分支名 提交对象hash为这个提交对象创建一个分支（时光机可以穿梭到过去的版本）
分支的注意点：在切换的时候一定要保证当前的分支一定是干净的。
Git status
允许切换的状态：
已提交
避免操作（虽然可以切换）：
初始化状态，未跟踪
初始化状态，已暂存
不允许切换：已修改或者第二次之后的已暂存
git存储：不想git log记录，临时提交。
Git stash将当前内容推到栈中
Git stash list查看栈内容
Git stash apply不出栈，利用栈顶
Git stash drop 删除栈顶
Git stash pop 上面两步
Git stash apply stash@（）指定应用
后悔药：
撤销工作的修改
Git checkout --filename
撤销暂存区的修改
Git reset HEAD filename
撤销版本区的修改
Git commit --amend（重新提交注释，如果想要重新提交内容可以通过先提交到缓存区使用--mend 再提交就能重置暂存区的内容版本）
Reset三部曲：soft（重置HEAD） mixed（重置暂存区） hard（重置工作目录，容易丢失文件）
Git reset --soft HEAD（commithash）
路径reset：所有路径reset都会省略第一步（不移动head）
Git reset （--mixed） commithash filename（使用commithash中的文件覆盖暂存区中的这个文件）
Git checkout branchname 和 git reset --hard commithash特别像
Checkout对于工作区是安全的但--hard不是，它是强制覆盖。
Checkout的HEAD不会带上分支--hard是带上分支。
Checkout路径
Checkout commithash filename动暂存区和工作目录
Checkout filename默认当前HEAD指向的提交对象，只动工作目录
Eslint：
下载：npm i eslint -D
工具类可以先使用而不用弄清楚源码级别
团队协作：github
通过github管理自己的仓库
先创建一个空的仓库：
登录github点击头像new一个repositories
只需要填写仓库名和描述即可
本地已经有仓库了，可以通过git命令将本地仓库推到远程仓库中
配置本地仓库对应远程仓库的别名和地址。（可以在github中有两种方式连接一个是http一个是ssh，这里使用http）
Git remote add 本地显示远程项目的别名 地址
Git remote -v查看有哪些远程仓库 别名和地址fetch和push
配置仓库的用户信息
Git config 配置这个仓库的用户信息等（通过这个可以查看这个有多少可以配置的）
Git config user.name “用户名”
Git config user.email ”email地址”
将项目推送到远程仓库
Git push 远程仓库别名 分支名（特定的分支）
需要注意的是需要使用凭据让远程仓库对你的身份做验证，可以通过windows中搜索凭据管理器。
到windows凭据将与github相关的内容
这样就需要使用GitHub登录口令了（之前登录过有凭据不会提示自动会登录上去进行验证）
这是第一次创建远程仓库需要的。如果使用已经有这个远程仓库，可以将远程仓库clone到本地。
在相应的远程仓库中右边看到clone仓库地址将它复制下来。
Git clone clone地址就会自动下载地址，不需要使用git init创建本地仓库
clone下来的仓库会自动的创建一个别名可以通过git remote -v查看。
提交之前查看一下配置信息git config --list
配置自己的用户信息git config --global --unset user.name取消配置全局用户名
需要在项目中设置用户权限 collaborators邀请git的用户。然后别人同意的时候才能登陆。
可以在项目设置中看见贡献者。
需要注意的是，总共有三个分支master，本地仓库master 跟踪分支（媒介） 远程分支
使用git fetch taobao可以读取项目但是这个项目不会在本地立刻生成而是下载到跟踪分支上，需要手动切换然后融合分支内容。
需要切换到taobao/master（会头尾分离）跟踪分支查看下载下来的内容git checkout taobao/master
切换到主分支git checkout master进行合并
Git merge taobao/master （进行快进合并，没有不干净的目录）
远程跟踪分支是从什么时候开始生成的？从git push之后生成的。或者clone下来的时候。
当自己想要上传一个分支时，就会生成一个远程跟踪分支，在远程仓库可以生成也会有一个分支。通过fetch也能下载这个分支。
下载下来之后这个分支也是需要切换的，不是只切换taobao/master就能拿到数据，还需要切换到这个taobao/分支来拿这个分支上的内容。如果必要需要创建一个新的本地分支来拿这个分支上的内容。
远程跟踪分支本地不能移动，只能通过fetch来移动移动分支。
由此可见，这些分支一旦多了就会浪费很多时间去下载上传分支内容。
（利用git clone时候才会有本地分支和远程跟踪分支是同步关系
使用git branch -u taobao/分支就能建立跟踪在master和taobao/master上，可以使用git pull直接拉去多个已跟踪分支git push直接提交多个建立了跟踪的分支。
）
Git checkout -b branchname servername/branchname创建一个本地分支跟踪远程分支并且切换到它
Git checkout --track servername/branchname创建一个branchname分支跟踪远程分支并且切换到它
git branch -u server/branch 将当前分支跟踪这个分支
Git branch -vv查看设置的所有的跟踪分支（git branch -v查看当前分支最新提交的对象）
Git push server --delete 远程分支名
Git remote prune server --dry-run列出仍在远程跟踪单远程已经被删除的无用分支
Git remote prune server清除上面命令列出来的远程跟踪
冲突：
Git本地操作会不会冲突？
典型合并的时候
Git远程协作的时候，会不会冲突？（跟踪的时候）
Push（同时push的时候不一定会成功，它会提示有冲突，需要git pull之后使用典型合并修改内容git add解决冲突git commit 提交再git push即可，这样就已经解决了这个问题，其他人git pull的时候就不会发生错误）
Pull（当拉取的时候，本地文件已经改变这时候就有可能发生操作需要暂存之后或者提交之后再解决冲突然后回到push冲突，拉去下来修改再提交）
Pull request流程
如果你想要参加某个项目，但是并没有推送权限的，这时候可以对这个仓库进行派生（fork）。通过fork可以向开源项目进行复制代码，参与开源项目，通过在fork之后的项目修改，修改之后通过项目下面有一个pull request向原来的项目发出pull request请求，通知原作者有哪些错误。作者可以在这个项目中看到一个pull request请求查看内容。可以告知请求有什么没有解决或者已经解决问题。选中confirm merge即可合并内容。
如果fork的信息已经过时了，需要更新fork（可以重新创建一个库）通过复制原来的库的地址创建新的远程仓库地址，可以获取最新信息。
远程：
本地分支
远程跟踪分支：push是创建
远程分支:初始化库或者推向远程的分支。
一个大型的项目：一般会有很多分支来给不同的团队进行合作。
有时候为了保护项目很可能只会让一个分支给一个团队使用，
这时候我们不能动master分支，而是动团队应用的分支。
频率最高的命令：
Git status
Git add
Git commit
Git push
Git pull
忽略文件常用
.DS_Store
Node_modules/
/dist/
Npm-debug.log*
Yarn-debug.log*
Yarn-error.log*
#editor directories and files编辑器很少用。Webstorm vscode
.idea
.vscode
*.suo
*.ntvs*
*.njsproj
*.sin
/dist/一般是用作打包文件。
.gitignore:内容规范
*.a忽略a后缀文件
!lib.a不忽略这个
/dist/根目录中的dist
可以在github.gitignore去查找对应语言的忽略文件可以使用node.gitignore
Ssh url:(http是一个公开的协议)（ssh是一种github私有的协议，不用填用户名和密码但是用的话需要做一些准备工作。）
Ssh keygen -t rsa -C 你的邮箱：生成公私钥
Ssh 文件位置：c\user\administrator\.ssh
将生成的公钥.pub的文件粘贴到账户的设置ssh and gpg keys上就能直接使用账户。之后这台电脑就可以直接参与这个账户的项目了，不过之后需要通过ssh协议获取项目内容和提交内容