1.几个重要概念

 工作区---------缓存区---------本地仓库--------远程仓库端
git init ------git add ------git commit-------git push

整个流程是串行过程，每次修改，如果不用git add 到缓存区，commit就不会提交到本地仓库。

Git文件的状态分为untracked和tracked

untracked文件是指新建的文件，尚未被git管理起来。

tracked又分为三种状态

已提交（committed），已修改（modified）和已暂存（staged）。已提交表示文件已被安全地保存在本地数据库中了；已修改表示修改了某个文件，但没有提交保存；已暂存表示把已修改的文件放在下次提交时要保存的清单中。

2.保存

git add xx 将修改 保存到缓存区
git commit xx 提交缓存区 保存到本地库
git push xx 本地库 推上远程仓库端

3.退回到指定版本

git log 查看所有提交的版本 （git log --pretty=oneline 单行显示）
git reflog 查看历史退回版本操作，包括对应版本号

git reset --hard HEAD^ 退回到上个版本
git reset --hard HEAD^^ 退回到上上个版本
git reset --hard commit_id 退回到指定版本

4.丢弃工作区的修改

• 场景1：当你仅仅是改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
• 场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步：第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
• 场景3：已经commit提交了修改 到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

场景1：add之前，丢弃工作区的修改

git checkout -- xxx (checkout让这个文件回到最近一次git commit或git add时的状态)

场景2：add之后commit之前，丢弃工作区的修改

需要两步：

1. git reset HEAD xxx 退回上次提交的某个文件到缓存区
2. git checkout -- xxx从缓存区退回某个文件

5. 远程

5.1git配置

https://www.cnblogs.com/zeo-to-one/p/8367801.html

5.2连接远程仓库(下面两种方式都可以)

找到github仓库对应的 URL

git remote add origin git@github.com:yourName/repositoryname.git
git remote add origin https://github.com/yourName/repositoryname.git

5.3推送到远程仓库

git push -u origin branch1  // 没什么卵用？？？

5.4 强制推送

https://blog.csdn.net/gddxz_zhouhao/article/details/53070317

 git push -f origin master

5.5 查看远程连接

git remote -v

分支操作

新建分支

git checkout -b branch1 【-b新建并HEAD到这个分支 -d删除分支 】

指定从某个分支下载

git clone -b  xxx  https://xxxx

查看分支状态

git branch      // 查看本地分支
git branch -a   // 包括远程分支

新建远程分支（先建远程分支，再push到远程分支）

git push origin local_branchxxx:remote_branchxxx // 建立分支 push都是这条吧

使用git branch -a查看所有分支，会看到remotes/origin/remote_branchxxx这个远程分支，说明新建远程分支成功。

删除远程分支（推送空分支到远程）

 git push origin  :remote_branchxxx

从远程分支下载

git clone -b branch_name  https://github.com/user_name/repositorie_name.git

常见错误

若公钥出现问题

https://blog.csdn.net/xc917563264/article/details/80533734

若提示Permissiondenied (publickey). fatal:Could not read from remote repository. Pleasemake sure you have the correct access rights and the repository exists.

https://www.cnblogs.com/wmr95/p/7852832.html

若提示Please make sure you have the correct access rights

and the repository exists.
https://blog.csdn.net/hanchao5272/article/details/79393393

ssh: connect to host github.com port 22: Operation timed out fatal: Could not read from remote repository.

https://www.gowhich.com/blog/781

Git: Connection reset by xx.74.223.xxx port 22

尝试用命令推一波，git push -u origin branch1

使用vscode总是让输入用户名和密码

1. git bash中设置Git 全局设置:
   git config --global user.name "用户名"
git config --global user.email "用户邮箱"

2. 设置让VSCode记住git账号和密码：
   git config --global credential.helper store

显示提交的信息

git cherry -v

查看最新的commit
git show

缓存太小，提交文件过大失败

Err：Git: fatal; the remote end hung up unexpectedly

修改设置git config文件的postBuffer的大小。（设置为500MB）

$ git config --local http.postBuffer 524288000
注：–local选项指定这个设置只对当前仓库生效。

reset revert rebase

查看版本号，可以使用命令git log查看，就是git commit -m "messgae"的时候对应的版本。

reset （复位 到 某一个版本）

git reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本。
适用场景： 如果想恢复到之前某个提交的版本，且那个版本之后提交的版本我们都不要了，就可以用这种方法。

使用git reset --hard 目标版本号命令将版本回退。当然可以反悔git reset --hard 目标版本号。目标版本号是commit后的字符commit 98165a464fc4cdbbb45fcdc42bb4df1bbb22e92f，输入前几位就可以。
reset之后再 git push 就不行了，因为这个版本是旧的，所以用git push -f强制推上去。

revert （重做 某一个版本）

适用场景： 如果我们想撤销之前的某一版本，但是又想保留该目标版本后面的版本，记录下这整个版本变动流程，就可以用这种方法。版本二已经没有了只是还有commit信息而已。

使用git revert -n 版本号反做，并使用git commit -m 版本名提交。

rebase （重新和到同一分支）

适用场景： 多人同时在一个branch下操作，可能导致提交不了需要先pull再push，这样导致多个分支产生，合并这些分支用rebase

merge

git merge <branch1>
该命令将指定分支导入到HEAD指定的分支。可能合并失败，1分支修改了同一行造成冲突，2分支删除了文件，3分支创建了同名文件。
冲突的地方用围起来<<<<<<< HEAD和 >>>>>>>，中间有冲突的改动会被 ======= 分割起来。

追踪每行代码的修改是谁写的

git blame 文件名 会显示每一行最后一次改动。

部分命令的区别与联系

git commit -a -m

-m 只提交暂存区的文件;
-ma 提交所有tracked的文件;

git add命令是个多功能命令，根据目标文件的状态不同，此命令的效果也不同

• 可以用它开始跟踪新文件，
• 把已跟踪的文件放到暂存区，
• 合并时把有冲突的文件标记为已解决状态等

通常我们提交git是：

git add .
git commit -m "messages"
git push

这三大步，而实际上，你只需要两条命令就够了，除非有新的文件要被添加进去[有新文件时需要先add改变文件状态]

git commit -am "messages"
git push

切换到tag

git checkout tag_name

但是，这时候 git 可能会提示你当前处于一个detached HEAD 状态。因为 tag 相当于是一个快照，是不能更改它的代码的。

如果要在 tag 代码的基础上做修改，你需要新建一个分支：

git checkout -b branch_name tag_name

代理问题导致无法访问github

https://blog.csdn.net/weixin_41010198/article/details/100095212

报错信息：
Resolving github.com (github.com)… 13.250.177.223
Connecting to github.com (github.com)|13.250.177.223|:443… connected.

查询代理（通过下面查询代理其实并没有返回相关的信息）
git config --global http.proxy

取消代理：查询到当前设置了代理，所以取消这个设置：
git config --global --unset http.proxy

合并commit

git rebase -i 需要合并的前一个commit；
弹出编辑将第二个，第三个到最后一个pick改为s，保存退出；
提示需要保留哪些，删除行dd，
有问题及时git rebase --abort即可

打patch

git am 0001-xxxxx直接打到commit上，无需add commit等

git apply是另外一种打patch的命令，
其与git am的区别是:
git apply并不会将commit message等打上去，打完patch后需要重新git add和git commit，
而git am会直接将patch的所有信息打上去，而且不用重新git add和git commit,author也是patch的author而不是打patch的人

根据最后一次commit生成patch
git format-patch -1 -2表示最近两次提交生成两个patch，生成的编号表示打patch的顺序0001–>0002

git show 显示最后一次commit的修改
git show xxxxxx 显示某次commit的修改

diff

查看没有add的内容变化
git diff
查看已经add但没有commit的内容变化
git diff -cached

已经提交
git diff A B 从commit A到B的所有变化
如git diff HEAD^ HEAD

某个src文件的变化
git diff A B src

存在有时间早于前面commit的情况

为什么？

rebase
rebase也叫变基，是指feature功能分支在从主干分支切出来之后，主干和功能分支独立前进几个提交之后。功能分支需要合入最新的主干代码而进行的操作。

merge
merge操作就没有rebase那么优雅干净了，直接将代码的修改插入。commit log的顺序按照提交先后。

如果你在一个分支上的提交有20个，而主干因为团队提交了30个commit，此时主干rebase进来的30个commit肯定排在前面。这样比较符合逻辑，因为虽然按照commit的时间，你有部分代码可能会在30个commit中间，但是并不是稳定的代码就是一堆bug，算不上产出。如果是以稳定为优先级，rebase肯定是最佳的。另外 rebase 的话你所有的提交都会在一起，查找起来会非常方便. git log点线图是一条线看起来非常舒服。
在查看一个经过rebase的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。
但rebase会丢失一些时间相关信息，如分支切出的时间。

通常rebae操作，
清晰教程：https://www.cnblogs.com/chenny7/p/7644318.html