整体需要看视频最终理解掌握
1、先在远端创建一个项目，如果项目添加了md文件，需要先git pull 拉去代码
2、本地代码进行git初始化
3、git remote add origin + 远端地址
4、git pull origin master --allow-unrelated-histories //把远程仓库和本地同步，消除差异，主要是创建的时候创建了read.md文件，所以去差异化。
5、将本地代码提交到远端命令： git push -u origin master （第一次提交的时候，必须加-u,往后就可以不用添加了）
二、git的一些常用命令
1、git stash 的常用命令
git stash 指的是将代码存储到了暂存区（stash)，并没有提交到本地仓库，运用场景：当我们在当前分支已经进行了大量的修改了，但是这个时候需要解决写之前的一些代码bug，此时我们的代码还没写完，可能有问题，没办法提交到本地仓库，所以我们需要将自己写的代码提交到暂存区中，并且恢复到写之前。
git stash save "save message" 执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。
git stash list 查看stash了哪些存储
git stash show 显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}
git stash apply 应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1}
git stash pop 命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}
git stash drop stash@{$num} 丢弃stash@{$num}存储，从列表中删除这个存储
git stash clear 删除所有缓存的stash
2、git fetch
先用一张图来理一下git fetch和git pull的概念：
可以简单的概括为：
git fetch是将远程主机的最新内容拉到本地，用户在检查了以后决定是否合并到工作本机分支中。
而git pull 则是将远程主机的最新内容拉下来后直接合并，即：git pull = git fetch + git merge，这样可能会产生冲突，需要手动解决。
下面我们来详细了解一下git fetch 和git pull 的用法。
3、git checkout
在日常的git操作中，git checkout——检出，是我们的常用命令。最为常用的两种情形是创建分支和切换分支。git checkout命令用于切换分支或恢复工作树文件。git checkout`是git最常用的命令之一，同时也是一个很危险的命令，因为这条命令会重写工作区。
4、git的reset和checkout的区别
在讲git的reset和checkout的区别之前，不得不说说HEAD、Index、Working Directory三个区域。
HEAD、Index、Working Directory
Git里有三个区域很重要
-
HEAD 指向最近一次commit里的所有snapshot
-
Index 缓存区域，只有Index区域里的东西才可以被commit
-
Working Directory 用户操作区域
下图解释了这三个区域的状态的变化过程：
初始化：
当你checkout分支的时候，git做了这么三件事情
-
将HEAD指向那个分支的最后一次commit
-
将HEAD指向的commit里所有文件的snapshot替换掉Index区域里原来的内容
-
将Index区域里的内容填充到Working Directory里
所以你可以发现，HEAD、Index、Working Directory这个时候里的内容都是一模一样的。
注意：一般会误解为，Index中的内容是空的，只有git add后才会有东西。实际上不是，Index里一直是有东西的。
所以，Git的所有操作就是对这三个区域的状态（或内容）的操作。
changed
如果你在Working Directory里修改了文件，git会发现Working Directory里的内容和Index区域里的内容不一致了。
这个时候git status的结果是：
# Changes not staged for commit:
Committed
最后，你就可以提交了
git commit
这样，就把HEAD的状态和Index以及Working Directory形成一致了。
reset
reset是用来修改提交历史的，想象这种情况，如果你在2天前提交了一个东西，突然发现这次提交是有问题的。
这个时候你有两个选择，要么使用git revert（推荐），要么使用git reset。
上图可以看到git reset是会修改版本历史的，他会丢弃掉一些版本历史。
而git revert是根据那个commit逆向生成一个新的commit，版本历史是不会被破坏的
已经push到远程仓库的commit不允许reset
上面已经讲了，git reset是会丢弃掉commit的。
如果commit已经被push到远程仓库上了，也就意味着其他开发人员就可能基于这个commit形成了新的commit，这时你去reset，就会造成其他开发人员的提交历史莫名其妙的丢失，或者其他灾难性的后果。
因此，一旦commit已经被push到远程仓库，那么是坚决不允许去reset它的。
不带文件参数的reset
前面章节已经说道Git有三个区域，Git的所有操作实际上是在操作这三个区域的状态（或内容）。
git reset配合不同的参数，对这三个区域会产生不同的影响。
reset实际上有3个步骤，根据不同的参数可以决定执行到哪个步骤(--soft, --mixed, --hard)。
-
改变HEAD所指向的commit(
--soft) -
执行第1步，将Index区域更新为HEAD所指向的commit里包含的内容(
--mixed) -
执行第1、2步，将Working Directory区域更新为HEAD所指向的commit里包含的内容(
--hard)–mixed
是默认参数，也就是说执行reset的时候不给就认为是--mixed`。下表说明了三种形式的git reset所产生的不同效果。
target代表想要将git指向到哪个commit
working index HEAD target working index HEAD
----------------------------------------------------
A B C D --soft A B D
--mixed A D D
--hard D D D
--merge (disallowed)
working index HEAD target working index HEAD
----------------------------------------------------
A B C C --soft A B C
--mixed A C C
--hard C C C
--merge (disallowed)带文件参数的reset
上面讲到的git reset实际上不带参数的，如果带上文件参数，那么效果会是怎样的？
HEAD不会动
将那个commit的snapshot里的那个文件放到Index区域中
需要注意的是带文件参数的git reset没有--hard, --soft这两个参数。只有--mixed参数。
unstage
下面这两个命令是一样的，都是reset到HEAD上。
git reset file.txt
git reset --mixed HEAD file.txt
这个例子的意义在于，unstage file，仔细想一想是不是这样？当你把一个文件stage到Index区域里后后悔了，那么只需要把Index区域里的这个文件恢复到最近一次commit的状态（也就是HEAD），那就相当于unstage了。
恢复到历史版本
下面这个命令就是将某个文件恢复到历史版本上。
reset eb43bf file.txt
这个例子的意思在于，把某个文件恢复到Index区域里，然后直接commit，这样就等于把这个文件恢复到历史版本了，这样依赖你都不需要去改动Working Directory了。
checkout
前面讲到checkout是会修改HEAD的指向，变更Index区域里的内容，修改Working Directory里的内容。
这看上去很像reset --hard，但和reset --hard相比有两个重要的差别
-
reset会把working directory里的所有内容都更新掉
-
checkout不会去修改你在Working Directory里修改过的文件
-
reset把branch移动到HEAD指向的地方
-
checkout则把HEAD移动到另一个分支
第二个区别可能有点难以理解，举例来说：假设你有两个分支master和develop，这两个分支指向不一样的commit，我们现在在develop分支上（HEAD指向的地方）
如果我们git reset master，那么develop就会指向master所指向的那个commit。
如果我们git checkout master，那么develop不会动，只有HEAD会移动。HEAD会指向master。看图：
带文件参数
当执行git checkout [branch] file时，checkout干了这件事情：
-
更新了index区域里file文件的内容
-
更新了working directory里file文件的内容
总结reset和checkout
head index work dir wd safe
Commit Level
reset --soft [commit] REF NO NO YES
reset [commit] REF YES NO YES
reset --hard [commit] REF YES YES NO
checkout [commit] HEAD YES YES YES
File Level
reset (commit) [file] NO YES NO YES
checkout (commit) [file] NO YES YES NO
“head”一列中的“REF”表示该命令移动了HEAD指向的分支引用，而“HEAD”则表示只移动了HEAD自身。 特别注意 “wd safe?” 一列，YES表示不会懂你在work dir的修改，NO代表会动你在work dir的修改。